Method and system for use of abstract classes for script implementation of HTTP to obtain information from devices

ABSTRACT

A method, system, and computer program product for extracting status information from within a script of a web page stored on a monitored device using an abstract class interface, the abstract class interface including a first function configured to obtain support information used to extract the status information and a second function configured to extract the status information from within the script of the web page using the support information. The method includes the steps of retrieving, from a first memory, vendor and model information of the monitored device; determining, based on the vendor and model information, at least one type of status information to obtain from the monitored device; obtaining, based on the web page and the vendor and model information, the support information using the first function of the abstract class interface; accessing the monitored device using the HTTP protocol, the obtained support information, and the second function of the abstract class interface to obtain the at least one type of status information from within the script of the web page; and storing, in a second memory, the status information obtained in the accessing step in association with the vendor and model information.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to the following commonly owned co-pendingU.S. patent applications:

1. Ser. No. 09/453,937 entitled “Method and System of Remote Diagnostic,Control, and Information Collection using a Dynamic Linked Library ofMultiple Formats and Multiple Protocols with Intelligent Formatter,”filed May 17, 2000;

2. Ser. No. 09/756,120 entitled “Method and System of Remote Support ofDevice Using Email,” filed Jan. 9, 2001;

3. Ser. No. 09/782,064 entitled “Method and System of Remote Diagnostic,Control, and Information Collection using a Dynamic Linked Library ofMultiple Formats and Multiple Protocols with Three-Level Formatting,”filed Feb. 14, 2001;

4. Ser. No. 09/921,707 entitled “Universal Controller in The WirelessNetworked Environment,” filed Aug. 6, 2001;

5. Ser. No. 09/953,358 entitled “Method and System of Remote Support ofDevice Using Email Through Data Transfer Module,” filed Sep. 17, 2001;

6. Ser. No. 09/953,359 entitled “Method and System for Remote Support ofDevice using Email for Sending Information Related to a MonitoredDevice,” filed Sep. 17, 2001;

7. Ser. No. 09/975,935 entitled “Method and System for Remote Support ofDevice Using Email Based Upon Pop3 With Decryption Capability ThroughVirtual Function,” filed Oct. 15, 2001;

8. Ser. No. 10/068,861 entitled “Method and Apparatus UtilizingCommunication Means Hierarchy to Configure or Monitor an InterfaceDevice,” filed Feb. 11, 2002;

9. Ser. No. 10/142,989 entitled “Verification Scheme for Email MessageContaining Information About Remotely Monitored Devices,” filed May 13,2002;

10. Ser. No. 10/142,992 entitled “Method for Scrambling Informationabout Network Devices That is Placed in Email Message,” filed May 13,2002;

11. Ser. No. 10/157,903 entitled “Method and Apparatus for ModifyingRemote Devices Monitored by a Monitoring System,” filed May 31, 2002;

12. Ser. No. 10/162,402 entitled “Method and System to Use HTTP andHtml/Xml for Monitoring the Devices,” filed Jun. 5, 2002;

13. Ser. No. 10/167,497 entitled “Method and System of Remote PositionReporting Device,” filed Jun. 13, 2002, which is a continuation of Ser.No. 09/575,702 (U.S. Pat. No. 6,421,608);

14. Ser. No. 10/225,290 entitled “Method and System for MonitoringNetwork Connected Devices with Multiple Protocols,” filed Aug. 22, 2002;

15. Ser. No. 10/328,003 entitled “Method of Accessing Information fromDatabase to be used to Obtain Status Information from the Web Pages ofRemotely Monitored Devices,” filed Dec. 26, 2002;

16. Ser. No. 10/328,008 entitled “Method of using Internal Structure toStore Database Information for Multiple Vendor and Model Support forRemotely Monitored Devices,” filed Dec. 26, 2002;

17. Ser. No. 10/328,026 entitled “Method of using Vectors of Structuresfor Extracting Information from the Web Pages of Remotely MonitoredDevices,” filed Dec. 26, 2002;

18. Ser. No. 10/372,939 entitled “Method and System for MonitoringNetwork Connected Devices with Multiple Protocols,” filed Feb. 26, 2003;

19. Ser. No. 10/460,150 entitled “Method for Efficiently StoringInformation used to Extract Status Information from a Device Coupled toa Network in a Multi-Protocol Remote Monitoring System,” filed Jun. 13,2003;

20. Ser. No. 10/460,151 entitled “Method for Efficiently ExtractingStatus Information Related to a Device Coupled to a Network in aMulti-Protocol Remote Monitoring System,” filed Jun. 13, 2003;

21. Ser. No. 10/460,404 entitled “Method for Parsing an InformationString to Extract Requested Information Related to a Device Coupled to aNetwork in a Multi-Protocol Remote Monitoring System,” filed Jun. 13,2003;

22. Ser. No. 10/460,408 entitled “Method and System for ExtractingVendor and Model Information in a Multi-Protocol Remote MonitoringSystem,” filed Jun. 13, 2003;

23. Ser. No. 10/670,505 entitled “Method and System for ExtractingInformation from Networked Devices in a Multi-Protocol Remote MonitoringSystem,” filed Sep. 26, 2003;

24. Ser. No. 10/670,604 entitled “Method and System for SupportingMultiple Protocols Used to Monitor Networked Devices in a RemoteMonitoring System,” filed Sep. 26, 2003;

25. Ser. No. 10/764,467 entitled “Method and System for Determining theType of Status Information to Extract from Networked Devices in aMulti-Protocol Remote Monitoring System,” filed Jan. 27, 2004;

26. Ser. No. 10/764,527 entitled “Method and System for ManagingProtocols Used to Obtain Status Information from a Network Device,”filed Jan. 27, 2004;

27. Ser. No. 10/764,569 entitled “Method and System for Managing Vendorand Model Information in a Multi-Protocol Remote Monitoring System,”filed Jan. 27, 2004;

28. Ser. No. 10/764,582 entitled “Method and System for InitializingProtocol Information Used to Extract Status Information from NetworkedDevices,” filed Jan. 27, 2004;

29. Ser. No. 10/927,158, filed Aug. 27, 2004;

30. Ser. No. 10/927,257, filed Aug. 27, 2004;

31. Ser. No. 10/927,283, filed Aug. 27, 2004;

32. Ser. No. 10/032,039, filed Jan. 11, 2005;

33. Ser. No. 10/032,016, filed Jan. 11, 2005;

34. Ser. No. 10/032,063, filed Jan. 11, 2005;

35. Ser. No. 10/032,008, filed Jan. 11, 2005;

36. Ser. No. 10/032,192, filed Jan. 11, 2005;

37. Application having Ser. No. 11/234,224, entitled “Method and Systemfor Script Implementation of HTTP to Obtain Information from RemoteDevices,” filed concurrently with the present application;

38. Application having Ser. No. 11/234,319, entitled “Database forMultiple Implementation of HTTP to Obtain Information from Devices,”filed concurrently with the present application; and

39. Application having Ser. No. 11/234,323, entitled “Method and Systemfor Script Processing in Script Implementation of HTTP to ObtainInformation from Devices,” filed concurrently with the presentapplication.

The disclosures of each of the above U.S. patents and patentapplications are incorporated herein by reference in their entirety.

The present invention includes the use of various technologiesreferenced and described in the references identified in the followingLIST OF REFERENCES by the author(s) and year of publication of thereference:

LIST OF REFERENCES

[1] Goldfart, C., The SGML Handbook. Clarendon Press (1990);

[2] Castro, E., HTML for the World Wide Web, Peachpit Press, Berkeley(1996); and

[3] Megginson, D., Structuring XML Documents, Prentice Hall, N.J.(1998).

The entire contents of each reference listed in the LIST OF REFERENCESare incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the monitoring of devices connected to anetwork. More particularly, it relates to a method, system, and computerprogram product for the remote monitoring of network-connected devicesusing multiple protocols.

2. Discussion of the Background

As is generally known, computer systems include hardware and software.Software includes a list of instructions that are created to operate andmanage hardware components that make up a computer system. Typically,computer systems include a variety of hardware components/devices thatinterface with one another. The computer system can be a stand-alonetype or a networked type. In a networked-type computer system, aplurality of distinct devices are connected to a network and thuscommunication between these distinct devices is enabled via the network.

Further, software for operating the hardware devices must be configuredin order to allow communication between the hardware devices so that thehardware devices are enabled to function cooperatively. Further, inorder to facilitate such a communication, it is also desirable forhardware devices to be monitored and the status of each hardware deviceidentified in order to ensure that each hardware device is functioningin an efficient manner.

For the purposes of this patent application, the inventor has determinedthat a hardware device that is controlling, configuring, or monitoringthe plurality of distinct devices or hardware devices would be referredto as a monitoring device and the hardware devices that are beingcontrolled, configured, or monitored by the monitoring device would bereferred to as “monitored devices.”

For hardware devices that are located on a network, it is desirable forthese devices to be monitored for maintenance, usage, or other purposes.However, in view of manufacturer differences relating to hardwaredevices and interfaces, it may be difficult for a monitoring device tocommunicate with various other devices connected to a network. Such adisadvantage most likely prevents network administrators from obtainingcrucial information about the performance and efficiency of the devicesconnected to the network.

The Simple Network Management Protocol (SNMP) is today a de-factoindustry standard for the monitoring and management of devices on datacommunication networks, telecommunication systems and other globallyreachable devices. Practically every organization dealing with computersand related devices expects to be able to centrally monitor, diagnose,and configure each such device across local- and wide-area networks.SNMP is the protocol that enables this interaction.

In order for a device to respond to SNMP requests, it is desirable toequip the device with the software that enables it to properly interpretan SNMP request, perform the actions required by that request, andproduce an SNMP reply. The SNMP agent software is typically a subsystemsoftware module residing in a network entity.

The collection of objects implemented by a system is generally referredto as a Management Information Base (MIB). An MIB may also be a databasewith information related to the monitoring of devices. Examples of otherMIB's include Ethernet MIB, which focuses on Ethernet interfaces; BridgeMIB, which defines objects for the management of 802.1D bridges, to namea few.

Using SNMP for monitoring devices is difficult as private MIB's includevalues that are hard to decipher without a valid key. A company usingSNMP for monitoring various devices connected to its network creates aunique identifier/key that is maintained as proprietary information ofthe company. For the most part, the results are displayed as binary orinteger values. Thus, using SNMP, results received from the devices thatare being monitored (“monitored devices”) fail to provide a user withthe status of the monitored devices in a user comprehensible manner.

Further, using SNMP, it is difficult for one to obtain detailedinformation about a monitored device without a valid key or access to aprivate MIB to decipher the results obtained as binary or integervalues. In addition, a given protocol (e.g., SNMP or HTTP/HTML) may failfor various reasons, such as time out or lost packets. Also, someinformation extracted from a given device using the multiple protocolsmay be duplicated for each protocol. Accordingly, if the extraction ofdata from the device is not properly managed in such situations, timeand memory inefficiencies result since some protocols require moreresources than other protocols. In addition, information extractionusing some protocols may require much less processing and memory thanusing others. Furthermore, some information obtained through oneprotocol may be more useful for the monitoring device than the oneobtained through another protocol.

SUMMARY OF THE INVENTION

The system and method of the present invention addresses solutions tothe above-identified problems by enabling monitoring of devices that areconnected to a network. Accordingly, a method of monitoring a deviceamong distinct devices communicatively coupled to a network isdescribed.

The method includes accessing a first database via a hardware accessmodule, the first database being configured to support a plurality ofcommunication protocols. The first database is stored with informationused by the plurality of communication protocols in order to obtainvarious information, such as manufacturer and model information of amonitored device. A communication protocol is selected from among aplurality of communication protocols, and the selected communicationprotocol is configured to receive status information from the monitoreddevice. The method further includes accessing the monitored device usingthe selected communication protocol and information from the firstdatabase, receiving status information from the accessed device, andstoring the received status information in a second database(DeviceODBC).

In another embodiment, the present invention provides a method ofmonitoring a device among distinct devices communicatively coupled to anetwork. A plurality of communication protocols may be used to retrieveinformation from a monitored device. For example, an SNMP protocol isfirst selected to access a monitored device, and device information thatis configured to be efficiently retrieved using the SNMP protocol isobtained. Subsequently, HTTP and FTP protocols are selected to obtaininformation that was incapable of efficient retrieval using the SNMPprotocol if the device supports the additional protocols. The selectionof protocols is performed by a protocol manager in conjunction withsupport information stored in a database.

In the present invention, a monitoring system enables the monitoring ofat least one device (monitored device) connected to a network, such as,for example, a LAN or a WAN. The monitored device is configured to havea unique IP address. The IP address allocated to the monitored device,and the details of the vendor/manufacturer for the monitored device, arestored in a database. By scanning the network and interrogating thedevices the IP addresses of the devices can be obtained. Such methodsare known. Therefore, it is assumed that IP addresses of the devices tobe monitored are already acquired and stored in a database.

The present invention specifies how to extract necessary informationfrom the HTML information received from a monitored device. Once a webpage location of the monitored device is accessed (i.e., through the IPaddress and the specified port), a specific web page corresponding tothe monitored device is displayed. Information in the web page is in theform of key and value pairs. For example, the toner level may be shownas “Black 100%” in the color printer web page. An HTML/XML parser isused to parse the page in order to retrieve required information fromthe information in the web page. The required information and parametervalues extracted from the web page using the HTML/XML parser are storedin the support database.

The present invention also identifies various vendors of monitoreddevices and the device models that are supported by the monitoringsystem as described herein. Since various vendors of the monitoreddevices present information about a monitored device in avendor-specific manner, the present invention enables the identificationof the vendor and model of the monitored device to determine theoperational status of the monitored device.

According to one aspect of the present invention, there is provided amethod, system, and computer program product for extracting informationrelated to a monitored device communicatively coupled to a network usingan HTTP communication protocol, comprising: retrieving, from a firstmemory, vendor and model information of the monitored device;determining, based on the vendor and model information, at least oneaccess function configured to access the monitored device using the HTTPprotocol to obtain device information of the monitored device, whereinthe at least one access function includes at least one of (1) a firstaccess function configured to obtain the device information from betweentags in a web page stored on the monitored device, and (2) a secondaccess function configured to obtain the device information from withina script in the web page; accessing the monitored device using the HTTPprotocol and each access function of the at least one access function toattempt to obtain the device information; and storing, in a secondmemory, the device information obtained in the accessing step, inassociation with the vendor and model information.

According to another aspect of the present invention, there is provideda method, system, and computer program product for extracting statusinformation from within a script of a web page stored on a monitoreddevice using an abstract class interface, the abstract class interfaceincluding a first function configured to obtain support information usedto extract the status information and a second function configured toextract the status information from within the script of the web pageusing the support information, the method comprising: (1) retrieving,from a first memory, vendor and model information of the monitoreddevice; (2) determining, based on the vendor and model information, atleast one type of status information to obtain from the monitoreddevice; (3) obtaining, based on the web page and the vendor and modelinformation, the support information using the first function of theabstract class interface; (4) accessing the monitored device using theHTTP protocol, the obtained support information, and the second functionof the abstract class interface to obtain the at least one type ofstatus information from within the script of the web page; and (5)storing, in a second memory, the status information obtained in theaccessing step in association with the vendor and model information.

According to another aspect of the present invention, there is provideda method, system, and computer program product for extracting statusinformation related to a monitored device communicatively coupled to anetwork using an HTTP communication protocol, comprising: retrieving,from a first memory, vendor and model information of the monitoreddevice; retrieving, based on the vendor and model information, at leastone implementation identifier, each implementation identifieridentifying a corresponding access function configured to access themonitored device using the HTTP protocol to obtain the statusinformation, wherein the at least one implementation identifieridentifies at least one of (1) a first access function configured toobtain the device information from between tags in a web page stored onthe monitored device, and (2) a second access function configured toobtain the device information from within a script in the web page;selecting an implementation identifier of the at least oneimplementation identifier; retrieving, from the first memory based onthe vendor and model information and the selected implementationidentifier, parameter values used to obtain the status information fromthe web page using the access function corresponding to theimplementation identifier; accessing the monitored device using the HTTPprotocol, the parameter values, and the access function corresponding tothe implementation identifier to attempt to obtain the statusinformation; and storing, in a second memory, the status informationobtained in the accessing step, in association with the vendor and modelinformation.

According to another aspect of the present invention, there is provideda method, system, and computer program product for extracting statusinformation from within a script of a web page stored on a monitoreddevice communicatively coupled to a network using an HTTP communicationprotocol, comprising: (1) obtaining, based on vendor and modelinformation, an identification of the web page and at least oneparameter string used to extract the status information from within thescript of the web page; (2) accessing the web page using theidentification of the web page and the HTTP protocol to obtain a line ofthe web page within the script; (3) parsing the obtained line of the webpage to determine if a parameter string of the at least one parameterstring is located within the obtained line; (4) if the parsing stepdetermines that the parameter string is not located within the obtainedline, repeating the accessing and parsing steps until the parameterstring is located; (5) if the parsing step determines that the parameterstring is located within the obtained line, determining whether allparameter strings in the at least one parameter string have beenlocated; (6) if the determining step determines that all parameterstrings in the at least one parameter string have not been located,repeating the accessing, parsing, repeating, and determining steps untilall parameter strings in the at least one parameter string have beenlocated; and (7) if the determining step determines that all parameterstrings have been located within the script, extracting the statusinformation from the web page based on the location of a last locatedparameter string.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the invention and many of the attendantadvantages thereof will be readily obtained as the same becomes betterunderstood by reference of the following detailed description whenconsidered in connection with the accompanying drawings, wherein:

FIG. 1 illustrates networked business office devices connected to anetwork of computers and databases through the Internet;

FIG. 2 illustrates the components of a digital image forming apparatus;

FIG. 3 illustrates the electronic components of the digital imageforming apparatus illustrated in FIG. 2;

FIG. 4 illustrates details of a multi-port communication interfaceillustrated in FIG. 3;

FIG. 5 illustrates an alternative system configuration in which businessoffice devices are either connected directly to the network or connectedto a computer which is connected to the network;

FIG. 6A is a block diagram illustrating a flow of information to andfrom an application unit using electronic mail;

FIG. 6B illustrates an alternative way of communicating using electronicmail in which a computer that is connected to the application unit alsoserves as a Message Transfer Agent (MTA);

FIG. 6C illustrates an alternative way of communicating using electronicmail in which an application unit includes a message transfer agent forexchanging electronic mail;

FIG. 6D illustrates an alternative way of communicating using electronicmail in which a mail server acts as a POP3 server to receive mail for anappliance/device and as an Simple Mail Transfer Protocol (SMTP) serverto send mail for the appliance/device;

FIG. 7 illustrates an alternative manner of sending messages across theInternet;

FIG. 8 illustrates an exemplary computer which may be connected to anappliance/device and used to communicate electronic mail messages;

FIG. 9 is a schematic representation of the overall system in accordancewith an exemplary embodiment of the present invention;

FIG. 10 illustrates modules used in the monitoring of the data and theirinterface functions in accordance with an exemplary embodiment of thepresent invention;

FIG. 11 shows details within the Monitor module and their callingfunctions between the sub-modules;

FIG. 12 shows the sequence of the init function of the Monitor moduleillustrated in FIG. 10;

FIG. 13 shows an exemplary sequence of the status monitor function todetermine the status of a monitored device by the MonitorManager, asshown in FIG. 11;

FIG. 14 shows a vector of the reference to the devices created byCDeviceFactory and used by the MonitorManager, as illustrated in FIG.12;

FIG. 15 illustrates the SParameter data structure used to storeparameter values necessary to access monitored devices according to oneembodiment of the present invention;

FIG. 16 illustrates a map structure used to store parameter valuesnecessary to access monitored devices according to one embodiment of thepresent invention;

FIG. 17 illustrates the organization of the monitor database used in oneembodiment of the present invention;

FIGS. 18 and 20 illustrate the organization of a support databasearranged according to communication protocol according to one embodimentof the present invention;

FIG. 19 is a diagram illustrating the organization of a support databasefor the HTTP protocol according to one embodiment of the presentinvention;

FIG. 21 illustrates the class structure of the HWaccess module accordingto one embodiment of the present invention;

FIG. 22 illustrates a data structure used in the HWaccess module of FIG.21 to maintain information necessary to access the monitored devices andto obtain status information from the monitored devices according to oneembodiment of the present invention;

FIG. 23 is a sequence diagram of the initialization of the HWaccesspackage when init( ) of the Monitor package is called;

FIG. 24 is a sequence diagram of canAccessIP( ) of the HWaccess packageto determine if the device is accessible by any protocol;

FIGS. 25A and 25B are the sequence diagrams of the obtainVendor( ),obtainModel( ), and obtainUniqueID( ) functions of the HWaccess package;

FIG. 26 shows a flowchart describing how the data structure used by thesoftware objects representing the monitored devices is updated todetermine which protocols are used to obtain status information for amonitored device according to one embodiment of the present invention;

FIG. 27 shows a flowchart describing the process of obtaining statusinformation from a monitored device using all of the communicationprotocols according to one embodiment of the present invention;

FIG. 28 illustrates the data structures used to store and maintain thestatus information of a monitored device of a specific vendor and modelfor each protocol according to one embodiment of the present invention;

FIG. 29 illustrates a package diagram for each of the protocol packagesof FIG. 21, wherein “XXX” refers to HTTP, FTP, or SNMP, for example;

FIG. 30 illustrates an alternative package diagram for each of theprotocol packages of FIG. 21, wherein “XXX” refers to HTTP, FTP, orSNMP, for example;

FIG. 31 illustrates the class structure of the SNMP package;

FIG. 32 shows the package diagram for the FTP package;

FIG. 33 is the package diagram of the HTTP package supporting theextraction of information from web pages within the script and betweentags;

FIG. 34 illustrates the data structure m_ImplementationMap of theCHTTPProtocol class;

FIG. 35 illustrates the data structure m_VendorModelSupportMap of theCHTTPProtocol class;

FIGS. 36A, 36B, and 36C illustrate the sequence diagram for theinitWithVendor( ), initWithModel( ), and initWithVendorModel( ) functionof CHTTPProtocol;

FIG. 37 is a flowchart for obtaining the status information of a devicevia HTTP;

FIG. 38 is a package diagram of the TagHTTPImplementation package usedto extract information from between the tags of a web page of a device;

FIG. 39 illustrates the map structure m_VendorModelWebInfoMap of theCScriptHTTPImplementation class;

FIG. 40 is a sample of the web page of a device for which the systemwill extract the status information;

FIG. 41 shows part of the HTML tags and java scripts which generate thedisplay of the web page of FIG. 40;

FIG. 42 is another sample of the web page of a device for which thesystem of the present invention will extract the status information;

FIG. 43 shows part of the HTML tags and java scripts that generate thedisplay of the web page of FIG. 42;

FIG. 44 shows the package diagram of the ScriptHTTPImplementationpackage, which extracts information from within the scripts of the webpage of a device;

FIGS. 45-47 are data structures of the CScriptHTTPImplementation classused for obtaining the model name, unique ID, and status informationfrom the web page of a device.

FIG. 48 is a flowchart describing the process of obtaining the statusinformation by the ScriptHTTPImplementation package;

FIG. 49 is a flowchart describing the process of obtaining the statusinformation from within the script of a web page by theScriptHTTPImplementation package;

FIG. 50 show the class diagram of the ScriptHTTPODBC package;

FIG. 51 shows the state diagram for processing the java script of a webpage of a device by derived classes of CAbsScriptProcess;

FIG. 52 shows sample data structures used by two derived classes ofCAbsScriptProcess;

FIG. 53 shows how a derived class of CAbsScriptProcess processes the webpage of a device containing java script;

FIG. 54 is a flowchart of the process of a derived class ofCAbsScriptProcess to extract information from the web page of a device;

FIG. 55A shows the members of the structure SInfoStructure used toextract information from the web page; and

FIG. 55B shows the sample values of the member of the structureSInfoStructure of FIG. 55A.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates a schematic having various devices and computers formonitoring, diagnosing, and controlling the operation of the devices.Specifically, FIG. 1 includes a first network 16, such as a Local AreaNetwork (LAN) connected to computer workstations 17, 18, 20, and 22. Theworkstations can be any type of computers including, e.g., PersonalComputer devices, Unix-based computers, Linux-based computers, or AppleMacintoshes. Also connected to the network 16 are a digitalimage-forming apparatus 24, a facsimile machine 28, and a printer 32. Aswould be appreciated by one of ordinary skill in the art, two or more ofthe components of the digital copier/printer 24 and the facsimilemachine 28 can be combined into a unified “image forming apparatus.” Forexample, the copier/printer 24, facsimile machine 28, the printer 32,and the workstations 17, 18, 20, and 22 may be referred to as machinesor monitored devices. In some configurations, one or more workstationsmay be converted to business office appliances. In addition, any networkbusiness office appliance/device can be attached to the network 16.Also, any workstation 17, 18, 20, and 22, and office appliance 27 canfunction as an intermediate monitoring device to poll the monitoreddevices on the network 16 and to send the collected data to themonitoring device.

One example of such a business office appliance is eCabinet® from RicohCorporation. Also, a facsimile server (not illustrated) may be connectedto the network 16 and have a telephone, cable, or wireless connection.Each of the digital copier/printer 24, facsimile machine 28, and printer32, in addition to being connected to the network 16, may also includeconventional telephone and/or cable and/or wireless connections 26, 30,and 34, respectively. As explained below, the monitored devices 24, 28,and 32, communicate with a remote monitoring, diagnosis, and controlstation, also referred to as a monitoring device, through, for example,the Internet via the network 16 or by a direct telephone, wireless, orcable connection.

In another exemplary business environment, monitored devices may includesuch devices as a multi-function imaging device, a scanner, a projector,a conferencing system, and a shredder. In another application, thenetwork 16 may be a home network where monitored devices are meters(electricity, gas, water) or appliances such as, for example, microwaveoven, washer, dryer, dishwasher, home entertainment system,refrigerator, rice cooker, heater, air condition, water heater, securitycamera.

In FIG. 1, a wide area network (WAN) (e.g., the Internet or itssuccessor) is generally designated by 10. The WAN 10 can be either aprivate WAN, a public WAN, or a hybrid type. The WAN 10 includes aplurality of interconnected computers and routers designated by 12A-12I.The manner of communicating over a WAN is known through a series ofRequest for Comments (RFC) documents available from the InternetEngineering Task Force (IETF) at www.ietf.org/rfc.html, including RFC821, entitled “Simple Mail Transfer Protocol”; RFC 822, entitled“Standard for the Format of ARPA Internet Text Message”; RFC 959,entitled “File Transfer Protocol (FTP)”; RFC 2045, entitled“Multipurpose Internet Mail Extensions (MIME) Part One: Format ofInternet Message Bodies”; RFC 1894, entitled “An Extensible MessageFormat for Delivery Status Notifications”; RFC 1939, entitled “PostOffice protocol—Version 3”; RFC 2068, “Hypertext TransferProtocol—HTTP/1.1”; and RFC 2298, entitled “An Extensible Message Formatfor Message Disposition Notifications.” The contents of each of thesereferences are incorporated herein by reference.

Transmission Control Protocol/Internet Protocol (TCP/IP) relatedcommunication is described, for example, in the book “TCP/IPIllustrated,” Vol. 1, The Protocols, by W. R. Stevens, fromAddison-Wesley Publishing Company, 1994, the entire contents of which isincorporated herein by reference. Volumes 1-3 of “Internetworking withTCP/IP” by Comer and Stevens are also incorporated herein by referencein their entirety.

Continuing to refer to FIG. 1, a firewall 50A is connected between theWAN 10 and the network 16. A firewall is a device that allows onlyauthorized computers on one side of the firewall to access a network,computers, or individual parts on the other side of the firewall.Firewalls are known and commercially available devices and/or software(e.g., ZoneAlarm from Zone Labs). Similarly, firewalls 50B and 50Cseparate the WAN 10 from a network 52 and a workstation 42,respectively. Additional details on firewalls can be found in “Firewallsand Internet Security” by W. R. Cheswick, and S. M. Bellovin, 1994,Addison Wesley Publishing, and “Building Internet Firewalls” by D. B.Chapman and E. D. Zwicky, 1995, O'Reilly & Associates, Inc. The entirecontents of those two references are incorporated herein by reference.

The network 52 is a conventional network and includes a plurality ofworkstations 56, 62, 68, and 74. These workstations may be located in adistributed fashion within different departments (e.g., sales, orderprocessing, accounting, billing, marketing, manufacturing, designengineering, and customer service departments) within a single company.In addition to the workstations connected via the network 52, aworkstation 42 that is not directly connected to the network 52 is alsoprovided. Information in a database stored in a disk 46 connected to theworkstation 42 may be shared using proper encryption and protocols overthe WAN 10 to the workstations connected directly to the network 52.Also, the workstation 42 includes a direct connection to a telephoneline and/or a cable network and/or a wireless network 44, and thedatabase in disk 46 may be accessed through the telephone line, thecable network, or via the wireless network 44. The cable network used bythis invention may be implemented using a cable network that istypically used to carry television programming, a cable that providesfor high-speed communication of digital data typically used withcomputers or the like, or any other desired type of cable.

In another embodiment, the workstation 42 can be a laptop computer, aPDA, a palm top computer, or a cellular phone with network capability.These devices may be used to access information stored in the databasestored in the disk 46.

Information related to digital copier/printer 24, office appliance 27,facsimile machine 28, or printer 32, respectively, may be stored in oneor more of the databases stored in the disks 46, 54, 58, 64, 70, and 76.Known databases include (1) SQL databases by Microsoft, IBM, Oracle, andSybase; (2) other relational databases; and (3) non-relational databases(including object-oriented databases from Objectivity, JYD SoftwareEngineering, and Orient Technologies). Each of the sales, orderprocessing, accounting, billing, customer service, marketing,manufacturing, and engineering departments may have their own databaseor may share one or more databases. Each of the disks used to storedatabases is a non-volatile memory such as a hard disk or optical disk.Alternatively, the databases may be stored in any storage deviceincluding solid state and/or semiconductor memory devices. For example,disk 64 may be stored with a marketing database, disk 58 may be storedwith a manufacturing database, disk 70 may be stored with an engineeringdatabase, and disk 76 may be stored with a customer service database.Alternatively, the disks 54 and 46 may be stored with one or more of thedatabases.

In addition to the workstations 56, 62, 68, 74, and 42 being connectedto the WAN 10, these workstations may also include a connection to atelephone line, cable, or wireless networks for providing a secureconnection to a machine/device being monitored, diagnosed, and/orcontrolled. Additionally, if one of the communication media is notoperating properly, one of the others may be automatically used, as abackup, for communication.

A feature of the present invention is the use of a “store-and-forward”mode of communication (e.g., Internet electronic mail, also referred toherein as e-mail) or transmission between a machine and acomputer/monitoring system for diagnosing and controlling the machine.Alternatively, the message which is transmitted may be implemented usinga mode of communication that makes direct, end-to-end connections (e.g.,using a socket connection to the ultimate destination) such as FTP andHyper Text Transfer Protocol (HTTP).

FIG. 2 illustrates the mechanical layout of the digital copier/printer24 illustrated in FIG. 1. In FIG. 2, 101 is a fan for the scanner, 102is a polygonal mirror used with a laser printer, and 103 designates an Fθ lens used to collimate light from a laser (not illustrated). Referencenumeral 104 designates a sensor for detecting light from the scanner.Reference numeral 105 designates a lens for focusing light from thescanner onto the sensor 104, and reference numeral 106 designates aquenching lamp used to erase images on the photoconductive drum 132.There is a charging corona unit 107 and a developing roller 108.Reference numeral 109 designates a lamp used to illustrate a document tobe scanned and elements 110, 111, and 112 designate mirrors forreflecting light onto the sensor 104. A drum mirror 113 is provided toreflect light to the photoconductive drum 132 originating from thepolygon mirror 102. A fan 114 is used to cool the charging area of thedigital image forming apparatus, and a first paper feed roller 115 isused for feeding paper from the first paper cassette 117, and areference numeral 116 designates a manual feed table. Similarly, asecond feed paper feed roller 118 is used in conjunction with the secondcassette 119. Reference numeral 120 designates a relay roller, 121designates a registration roller, 122 designates an image densitysensor, and 123 designates a transfer/separation corona unit. Referencenumeral 124 designates a cleaning unit, 125 designates a vacuum fan, 126designates a transport belt, 127 designates a pressure roller; and 128designates an exit roller. A hot roller 129 is used to fix toner ontothe paper, 130 designates an exhaust fan, and a main motor 131 is usedto drive the digital copier/printer 24.

FIG. 3 is a block diagram illustrating the electronic components of thedigital copier/printer 24 of FIG. 2, wherein CPU 160 is a microprocessorthat acts as a controller of the apparatus. Random access memory (RAM)162 stores dynamically changing information including operatingparameters of the digital copier/printer 24. A non-volatile memory(e.g., a read only memory (ROM) 164 or a Flash Memory) stores programcode used to run the digital copier/printer as well as static-statedata, describing the copier/printer 24 (e.g., the model name, modelnumber, serial number of the device, and default parameters).

A multi-port network interface 166 is provided to enable the digitalcopier/printer 24 to communicate with external devices through at leastone communication network. Reference number 168 represents a wireless orcellular network, and numeral 170 represents another type of networkdifferent from the network identified at 168. Additional details of themulti-port network interface are set forth with respect to FIG. 4. Aninterface controller 172 is used to connect an operation panel 174 to asystem bus 186. The operation panel 174 includes standard input andoutput devices found on a digital copier/printer 24 including a copybutton, keys to control the operation of the image forming apparatussuch as, for example, number of copies, reduction/enlargement,darkness/lightness, etc. Additionally, a liquid crystal display may beincluded within the operation panel 174 to display parameters andmessages of the digital copier/printer 24 to a user.

A local connection interface 171 is a connection through local portssuch as RS232, the parallel printer port, USB, and IEEE 1394. FireWire(IEEE 1394) is described in Wickelgren, I., “The Facts About “FireWire”,IEEE Spectrum, April 1997, Vol. 34, Number 4, pp. 19-25, the entirecontents of which are incorporated herein by reference. Preferably, a“reliable” communication protocol is used which includes error detectionand retransmission.

A storage interface 176 connects storage devices to the system bus 186.For example, the storage devices include a flash memory 178, which canbe substituted by a conventional Electrically Erasable Programmable ReadOnly Memory (EEPROM), and a disk 182. The disk 182 may be a hard disk,optical disk, and/or a floppy disk drive. Additional memory devices maybe connected to the digital copier/printer 24 via connection 180. Theflash memory 178 is used to store semi-static state data that describesparameters of the digital copier/printer 24 that infrequently changeover the life of the apparatus 24. Such parameters include, for example,the options and configuration of the digital copier/printer. An optioninterface 184 allows additional hardware, such as an external interface,to be connected to the digital copier/printer 24. A clock/timer 187 isutilized to keep track of both the time and date and also to measureelapsed time.

FIG. 3 also illustrates the various sections making up the digitalcopier/printer 24. Reference numeral 202 designates a sorter andcontains sensors and actuators that are used to sort the output of thedigital copier/printer 24. A duplexer 200 allows performance of a duplexoperation. The duplexer 200 includes conventional sensors and actuators.A large capacity tray unit 198 is provided for allowing paper traysholding a large number of sheets. As with the duplexer 200, the trayunit 198 includes conventional sensors and actuators as well.

A paper feed controller 196 is used to control the operation of feedingpaper into and through the digital image forming device. A scanner 194is used to scan images into the digital image forming device andincludes conventional scanning elements such as a light, mirror, etc.Additionally, scanner sensors are used such as a home position sensor todetermine that the scanner is in the home position, and a lampthermistor is used to ensure proper operation of the scanning lamp. Aprinter/imager 192 prints the output of the digital image formingdevice, and includes a conventional laser printing mechanism, a tonersensor, and an image density sensor. The fuser 190 is used to fuse thetoner onto the page using a high temperature roller and includes an exitsensor, a thermistor to assure that the fuser 190 is not overheating,and an oil sensor. Additionally, there is an optional unit interface 188used to connect to optional elements of the digital image forming devicesuch as an automatic document feeder, a different type ofsorter/collator, or other elements which can be added to the digitalimage forming device. Other elements include a GPS unit that canidentify the location of the device.

FIG. 4 illustrates details of the multi-port network interface 166. Thedigital image forming device may communicate to external devices througha cellular interface 227, a wireless interface 228, or an Ethernetinterface 230, which connects to a LAN 170. Other interfaces mayinclude, but are not limited to, a Digital Subscriber Line (DSL)(original DSL, concentric DSL, and asymmetric DSL). A single devicewhich connects to both a Local Area Network and a telephone line iscommercially available from Intel and is known as Intel Pro10/100+Modem.

The CPU or other microprocessor or circuitry executes a monitoringprocess to monitor the state of each of the sensors of the digital imageforming device, and a sequencing process is used to execute theinstructions of the code used to control and operate the digital imageforming device. Additionally, there is (1) a central system controlprocess executed to control the overall operation of the digital imageforming device, and (2) a communication process used to assure reliablecommunication to external devices connected to the digital image formingdevice. The system control process monitors and controls data storage ina static state memory (e.g., the ROM 164 of FIG. 3), a semi-staticmemory (e.g., the flash memory 178 or disk 182), or the dynamic statememory (e.g., a volatile or non-volatile memory (e.g., the RAM 162, theflash memory 178, or disk 182). Additionally, the static state memorymay be a device other than the ROM 164 such as a non-volatile memoryincluding either of the flash memory 178 or disk 182.

The above details have been described with respect to a digital imageforming device, but the present invention is equally applicable to otherbusiness office machines or devices such as an analog copier, afacsimile machine, a scanner, a printer, a facsimile server, projector,conferencing equipment, shredder, or other business office machines, abusiness office appliance, or other appliances (e.g., a microwave oven,VCR, DVD, digital camera, digital camcorders, cellular phone, palm topcomputer). Additionally, the present invention includes other types ofdevices that operate using store-and-forward or direct connection-basedcommunication. Such devices include metering systems (including gas,water, or electricity metering systems), vending machines, or anymechanical device (e.g., automobiles, motorcycles, washer, dryer) thatneeds to be monitored during operation or remote diagnosis. In additionto monitoring special purpose machines and computers, the invention canbe used to monitor, control, and diagnose a general purpose computerthat would be the monitored and/or controlled device.

FIG. 5 illustrates an alternative system diagram of the presentinvention in which different devices and subsystems are connected to theWAN 10. However, there is no requirement to have each of these devicesor subsystems as part of the invention. Each component or subsystemillustrated in FIG. 5 is individually part of the invention. Further,the elements illustrated in FIG. 1 may be connected to the WAN 10 whichis illustrated in FIG. 5. In FIG. 5, there is illustrated a firewall50-1 connected to an intranet 260-1. A service machine 254 connected tothe intranet 260-1 includes therein, or has connected thereto, data 256that may be stored in a database format. The data 256 includes history,performance, malfunction, and any other information such as statisticalinformation of the operation or failure or set-up of the monitoreddevices, or configuration information such as which components oroptional equipment is included with the monitored devices. The servicemachine 254 may be implemented as the device or computer that requeststhe monitored devices to transmit data, or that requests that remotecontrol and/or diagnostic tests be performed on the monitored devices.The service machine 254 may be implemented as any type of device, and ispreferably implemented using a computerized device such as a generalpurpose computer. Also, Service Machine 254 may consist of multiplecomputers over the network with diverse database including billing,accounting, service processing, parts tracking and reports.

Another sub-system of FIG. 5 includes a firewall 50-2, an intranet260-2, and a printer 262 connected thereto. In this sub-system, thefunctions of sending and receiving electronic messages by the printer262 (and similarly by a copier 286) are performed by (1) circuitry, (2)a microprocessor, or (3) any other type of hardware contained within ormounted to the printer 262 (i.e., without using a separate generalpurpose computer).

An alternate type of sub-system includes the use of an Internet ServiceProvider 264, which may be any type of Internet Service Provider (ISP),including known commercial companies such as America Online, Earthlink,and Niftyserve. In this sub-system, a computer 266 is connected to theISP 264 through a digital or analog modem (e.g., a telephone line modem,a cable modem, modems which use any type of wires such as modems usedover an Asymmetric Digital Subscriber Line (ADSL), modems that use framerelay communication, wireless modems such as a radio frequency modem, afiber optic modem, or a device that uses infrared light waves). Further,a business office device 268 is connected to the computer 266. As analternative to the business office device 268 (or any other deviceillustrated in FIG. 5), a different type of machine may be monitored orcontrolled such as a digital copier, any type of appliance, securitysystem, or utility meter, such as an electrical, water, or gas utilitymeter, or any other device discussed herein.

Also illustrated in FIG. 5 is a firewall 50-3 connected to a network274. The network 274 may be implemented as any type of computer network,(e.g., an Ethernet or token ring network). Networking software that maybe used to control the network includes any desired networking softwareincluding software commercially available from Novell or Microsoft. Thenetwork 274 may be implemented as an intranet, if desired. A computer272 connected to the network 274 may be used to obtain information froma business office device 278 and generate reports such as reportsshowing problems that occurred in various machines connected to thenetwork, and a monthly usage report of the devices connected to thenetwork 274. In this embodiment, a computer 276 is connected between thebusiness office device 278 and the network 274. This computer receivescommunications from the network and forwards the appropriate commands ordata, or any other information, to the business office device 278.

Communication between the business office device 278 and the computer276 may be accomplished using wire-based or wireless methods including,but not limited to, radio frequency connections, electrical connections,and light connections (e.g., an infrared connection, or a fiber opticsconnection). Similarly, each of the various networks and intranetsillustrated in FIG. 5 may be established using any desired mannerincluding through the establishment of wireless networks such as radiofrequency networks. The wireless communication described herein may beestablished using spread spectrum techniques including techniques whichuse a spreading code and frequency hopping techniques such as thefrequency hopping wireless technique disclosed in the BluetoothSpecification (available at the World Wide Web site www.bluetooth.com),which is incorporated herein by reference.

Another sub-system illustrated in FIG. 5 includes a firewall 50-4, anintranet 260-4, a computer 282 connected thereto, a business officeappliance 285 and a copier 286. The computer 282 may be used to generatereports and request diagnostic or control procedures. These diagnosticand control procedures may be performed with respect to the businessoffice appliance 285 and the copier 286 or any of the other devicesillustrated in or used with FIG. 5. While FIG. 5 illustrates a pluralityof firewalls, the firewalls are preferable, but optional equipment, andtherefore, the invention may be operated without the use of firewalls,if desired. For the monitoring and controlling of the networkedequipment, any computers (266, 272, or 282) can be used instead of 254.In addition, any computer may access 254 to retrieve necessary deviceinformation or usage information through the web.

FIG. 6A illustrates a device/appliance 300 connected to a typical e-mailexchange system, which includes components 302, 304, 306, 308, 310, 312,314, 316, and 318, which may be implemented in a conventional manner,and are adapted from FIG. 28.1 of Stevens, above. A computer interface302 interfaces with any of the application units or devices/appliances300 described herein. While FIG. 6A illustrates that thedevice/appliance 300 is the sender, the sending and receiving functionsmay be reversed in FIG. 6A. Furthermore, if desired, the user may notneed to interface with the device/appliance 300 at all. The computerinterface 302 then interacts with a mail agent 304. Popular mail agentsfor Unix include MH, Berkeley Mail, Elm, and Mush. Mail agents for theWindows family of operating systems include Microsoft Outlook andMicrosoft Outlook Express. At the request of the computer interface 302,the mail agent 304 creates e-mail messages to be sent and, if desired,places these messages to be sent in a queue 306. The mail to be sent isforwarded to a Message Transfer Agent (MTA) 308. A common MTA for Unixsystems is Sendmail. Typically, the message transfer agents 308 and 312exchange communications using a TCP/IP connection 310. Notably, thecommunication between the message transfer agents 308 and 312 may occurover any size network (e.g., WAN or LAN). Further, the message transferagents 308 and 312 may use any communication protocol. In one embodimentthe present invention, elements 302 and 304 of FIG. 6A reside in thelibrary to monitor the usage of the application unit.

From the message transfer agent 312, e-mail messages are stored in usermailboxes 314, which are transferred to the mail agent 316 andultimately transmitted to the user at a terminal 318 which functions asa receiving terminal.

This “store-and-forward” process relieves the sending mail agent 304from having to wait until a direct connection is established with themail recipient. Because of network delays, the communication couldrequire a substantial amount of time during which the application wouldbe unresponsive. Such delays in responsiveness may generally beunacceptable to users of the application unit. By using e-mail as thestore-and-forward process, retransmission attempts after failures occurautomatically for a fixed period of time (e.g., three days). In analternate embodiment, the application can avoid waiting by passingcommunicating requests to one or more separate threads. Those threadscan then control communication with the receiving terminal 318 while theapplication begins responding to the user interface again. In yetanother embodiment in which a user wishes to have communicationcompleted before continuing, direct communication with the receivingterminal is used. Such direct communication can utilize any protocol notblocked by a firewall between the sending and receiving terminals.Examples of such protocols include Telnet, File Transfer Protocol (FTP),and Hyper Text Transfer Protocol (HTTP).

Public WANs, such as the Internet, are generally not considered to besecure. Therefore, if it is desired to keep messages confidential,messages transmitted over the public WANs (and multi-company privateWANs) can be encrypted. Encryption mechanisms are known and commerciallyavailable and may be used with the present invention. For example, a C++library function, crypt( ), is available from Sun Microsystems for usewith the Unix operating system. Encryption and decryption softwarepackages are known and commercially available and may also be used withthis invention. One such package is PGP available from PGP Corporation.

As an alternative to the general structure of FIG. 6A, a single computerthat functions as the computer interface 302, the mail agent 304, themail queue 306, and the message transfer agent 308 may be used. Asillustrated in FIG. 6B, the device/appliance 300 is connected to acomputer 301, which includes the message transfer agent 308.

A further alternative structure is shown in FIG. 6C in which the messagetransfer agent 308 is formed as part of the device/appliance 300.Further, the message transfer agent 308 is connected to the messagetransfer agent 312 by a TCP/IP connection 310. In the embodiment of FIG.6C, the device/appliance 300 is directly connected to the TCP/IPconnection 310 with an e-mail capability. One use of the embodiment ofFIG. 6C includes using a facsimile machine with an e-mail capability(e.g., as defined in RFC 2305 (a simple mode of facsimile using Internetmail)) as the device/appliance 300.

FIG. 6D illustrates a system in which a device/appliance 300 does not byitself have the capability to directly receive e-mail, but has aconnection 310 to a mail server/POP3 server including a message transferagent 308 and a mail box 314 so that the device/appliance 300 uses thePOP3 protocol to retrieve received mail from the mail server.

FIG. 7 illustrates an alternative implementation of transferring mailand is adapted from FIG. 28.3 of Stevens referenced previously. FIG. 7illustrates an electronic mail system having a relay system at each end.The arrangement of FIG. 7 allows one system at an organization to act asa mail hub. In FIG. 7, there are four MTAs connected between the twomail agents 304 and 316. These MTAs include local MTA 322A, relay MTA328A, relay MTA 328B, and local MTA 322D. The most common protocol usedfor mail messages is SMTP (Simple Mail Transfer Protocol) which may beused with this invention, although any desired mail protocol may beutilized. In FIG. 7, 320 designates a sending host which includes thecomputer interface 302, the mail agent 304, and the local MTA 322A. Thedevice/appliance 300 is connected to, or alternatively included within,the sending host 320. As another case, the device/appliance 300 and host320 can be in one machine where the host capability is built into thedevice/appliance 300. Other local MTAs 322B, 322C, 322E, and 322F mayalso be included. Mail to be transmitted and received may be queued in aqueue of mail 306B of the relay MTA 328A. The messages are transferredacross the TCP/IP connection 310 (e.g., an Internet connection or aconnection across any other type of network).

The transmitted messages are received by the relay MTA 328B and ifdesired, stored in a queue of mail 306C. The mail is then forwarded tothe local MTA 322D of a receiving host 342. The mail may be placed inone or more of the user mailboxes 314 and subsequently forwarded to themail agent 316, and finally forwarded to the user at a terminal 318. Ifdesired, the mail may be directly forwarded to the terminal without userinteraction.

The various computers used in the present invention, including thecomputers 266 and 276 of FIG. 5, may be implemented as illustrated inFIG. 8. Further, any other computer used in this invention may beimplemented in a similar manner to the computer illustrated in FIG. 8,if desired, including the service machine 254, computer 272, andcomputer 282 of FIG. 5. However, not every element illustrated in FIG. 8is required in each of those computers.

In FIG. 8, the computer 360 includes a CPU 362 which may be implementedas any type of processor including commercially availablemicroprocessors from companies such as Intel, AMD, Motorola, Hitachi andNEC. There is a working memory such as a RAM 364, and a wirelessinterface 366 that communicates with a wireless device 368. Thecommunication between the interface 366 and device 368 may use anywireless medium (e.g., radio waves or light waves). The radio waves maybe implemented using a spread spectrum technique such as Code DivisionMultiple Access (CDMA) communication or using a frequency hoppingtechnique such as that disclosed in the Bluetooth specification.

Computer 360 includes a ROM 370 and a flash memory 371, although anyother type of non-volatile memory (e.g., Erasable Programmable ROM, oran EEPROM) may be used in addition to or in place of the flash memory371. An input controller 372 has connected thereto a keyboard 374 and amouse 376. There is a serial interface 378 connected to a serial device380. Additionally, a parallel interface 382 is connected to a paralleldevice 384, a universal serial bus (USB) interface 386 is connected to auniversal serial bus device 388, and also there is an IEEE 1394 device400, commonly referred to as a fire wire device, connected to an IEEE1394 interface 398. A system bus 390 connects the various elements ofthe computer 360. A disk controller 396 is connected to a floppy diskdrive 394 and a hard disk drive 392. A communication controller 406allows the computer 360 to communicate with other computers (e.g., bysending e-mail messages) over a network 404. An I/O (Input/Output)controller 408 is connected to a printer 410 and a hard disk 412, forexample using a SCSI (Small Computer System Interface) bus. There isalso a display controller 416 connected to a CRT (Cathode Ray Tube) 414,although any other type of display may be used including a liquidcrystal display, a light emitting diode display, a plasma display, etc.

Referring now to FIG. 9, there is shown a schematic representation ofthe overall system 900 in accordance with an exemplary embodiment of thepresent invention. System 900 is shown to include a plurality ofdevices, for example, a laser printer 908, a scanner 910, a networkdevice 912, and a multi-function printer 914, all connected to a network100. The plurality of devices are generally referred to herein as“monitored devices.” The system 900 also includes aworkstation/monitoring system 902 (hereinafter referred to as acontroller 902), connected to the network 100 for monitoring andcontrolling the monitored devices 908, 910, 912, and 914. Each of themonitored devices 908, 910, 912, and 914 are given a unique address. Forexample, an IP address assigned to a device serves as a unique addressfor the device. Thus, a user at controller 902 is able to access arespective device among the monitored devices 908-914 by accessing theunique IP address assigned to the respective monitored device. It willbe appreciated that the present invention is not limited to using IPaddresses to uniquely identify devices connected to a network.

The controller 902, upon accessing a device among the monitored devices908-914, obtains various information through SNMP or/and HTTP protocols.Such information includes detailed information about the operationalstatus of the device including troubleshooting information. For example,controller 902 accesses and obtains the jam location of a particulardevice and sends a message to the person in charge of the device toclear the jam. The operational status/details of the laser printer 908include such details as toner level, indication of paper jam, quantityof print paper in printer trays, etc.

It will be appreciated that the controller 902 may be either physicallyconnected or wirelessly coupled to the network 100. For example, apersonal digital assistant (PDA) 920 or a laptop computer 922, shown tobe wirelessly coupled to the network 100, may also be used as acontroller 902. An access point 924 acts as an interface to enablewireless communications between the network 100 and PDA 922 or laptopcomputer 922. Henceforth, the present invention will be described withthe assumption that the controller 902 will be controlling andmonitoring the status of the monitored devices connected to the network.

The network 100 facilitates communication between the controller 902 andthe monitored devices 908-914 to enable monitoring and control of suchmonitored devices. The number of devices that are connected to thenetwork is not limiting of the present invention. It will be appreciatedthat the network 100 may be a local area network (LAN) or a wide areanetwork (WAN). Likewise, the monitored devices 908, 910, 912, and 914are shown to be merely exemplary.

The controller 902 is communicatively coupled to a storage device 904and a database 906. The storage device 904 includes a hard disk, opticaldisk, and/or an external disk drive. The database 906 is communicativelylinked to the storage device 904, and includes a Relational DatabaseManagement System (RDBMS) for easy search and retrieval of data storedin the storage device 904. The storage device 904 preferably storesdetailed information about each of the monitored devices 908-914. Forexample, detailed information, such as the make, model, and variousfunctions and trouble-shooting details of the laser printer 908 arestored in the storage device 904. Also, deviation values about theoperational status of the laser printer compared to predeterminedreference values may also be stored in the storage device 904. Althoughthe database 906 and the storage device 904 are described to becommunicatively coupled to the controller 902, it will be appreciatedthat the controller 902 may be built with the storage device and thedatabase installed therein. In such a case, the storage device 906 andthe database 904 would be depicted as being internal to the controller902.

The controller 902 is installed with software in order to facilitatemonitoring and control of the plurality, of devices 908-914. SimpleNetwork Management Protocol (SNMP), File Transfer Protocol (FTP) andHyper Text Transfer Protocol (HTTP) are used by the controller 902 formonitoring the plurality of devices 908-914 and the data received fromthe plurality of devices 908-914 is presented in the form of ASN.1Binary format or HTML or XML formats, as shown in 950.

Although FIG. 9 illustrates only the imaging devices, the network forcommunicating information between the monitoring device and theplurality of monitored devices may include the home network where theappliances and meters are connected to the network. It will beappreciated that data collected by the controller/workstation 902 can besent through e-mail, FTP, or any other communication protocol means to aremote device for further processing. Though the monitoring station 902,PDA 920, or the laptop 922 can be the controller that collects the dataand stores the data or sends the data through a communication protocol,it will be appreciated that the controller can be any of the devicesconnected to the network. Any of the network devices (e.g. printers) cancontain the monitoring system capable of monitoring the status of otherdevices in the network, storing the collected data and/or sending thecollected data through any other communication protocol means (e.g.,e-mail, FTP). The Xerox Document 4025 and HP LaserJet 9000 are bothcapable of sending e-mail.

The monitoring station 902 can send the status information to a remotelocation by e-mail via SMTP. As shown in FIG. 9, the monitoring station902 sends the status information in an e-mail via SMTP server 926 to aremote location or remote network. The remote location has a POP3 server930 to receive the email. A workstation 940 communicates with the POP3server 930 to retrieve the email containing the status information. Theworkstation 940 may store the status information in a database 960.Email allows the status information to be easily transmitted to a remotelocation. The status information may be in the email message or in anattachment. The status information may be encoded to provide securetransmission of the data. Other protocols such as FTP, HTTP, or webservice can be used to transmit the information to a remote location.

Monitoring System Architecture

FIG. 10 illustrates a monitoring system 1000 (and associated interfacefunctions) used in the monitoring of data associated with remote devicesaccording to an exemplary embodiment of the present invention. Themonitoring system 1000 includes the software module MonitorService 1004,which is a computer resident program such as Service in NT or Windows2000, and Daemon in Unix. In a preferred embodiment, the monitoringsystem is implemented using an objected-oriented software environment.Also included in the monitoring system 1000 are a Timer module 1002 andMonitor module 1006. Timer module 1002 and Monitor module 1006 arelibrary functions to be called by the MonitorService module 1004. Forexample, MonitorService 1004 initializes the Timer module 1002 bycalling the InitTimer 1003 function and obtains delay and actionparameters by calling obtainDelayAndAction (int &, int &) function. Theinit( ) function is also called by the MonitorService module 1004 toinitialize various modules in the Monitor module 1006, as illustrated inFIG. 13. The init( ) function can be used to obtain the IP address andparameter value assigned to a monitored device through an externalsource containing IP addresses, parameter names and values collectedthrough known methods. The Monitor module 1006 is communicativelycoupled to a support database 1024 and to a monitor database 1014, whichare described in more detail below.

Once the IP address of a monitored device is obtained, the IP address isused by the monitoring system to contact the monitored device to obtaininformation such as, manufacturer (vendor) and model information. Someof the functions executed by the monitoring system 1000 include:

void initTimer(void)

This function initializes the Timer. In particular, this functiontriggers the Timer object to get the timing information from theregistry.

void obtainDelayAndAction(int & out_nDelay, int & out_nAction)

This function returns the delay time in seconds for ::Sleep function(need to multiply 1000) and the action indicator. The action indicatoris defined as follows: 0=event checking; 1=sending the monitored data;and 2=monitoring and storing the data into the local database.

int init(void)

This function initializes the Monitor. In addition, it creates thedevices to be monitored. The return int is the error code in which zerois defined as no error.

int monitorStatus(int in_nAction)

This function monitors the preset information. The return int is theerror code in which zero is defined as no error.

int end(void)

This function cleans up the Monitor before closing the objects. Thereturn int is the error code in which zero is defined as no error.

Monitor Module

FIG. 11 shows the structural details of the Monitor module 1006,including the various software sub-modules, and the calling functionsbetween the sub-modules of the Monitor module 1006. The Monitor module1006 includes a Common module 1101 that contains classes used by manymodules, a MonitorManager module 1102 that manages the other sub-modules(including the DeviceODBC module 1104, the Device module 1110, and theHWaccess module 1116) to complete the tasks defined by interfacefunctions as illustrated in FIG. 10. Specifically, the DeviceODBC module1104 is accessed in order to access external device information throughthe standard interface. The HWaccess module 1116 obtains vendor, model,unique ID, and status information from the monitored devices using aselected communication protocol from among a plurality of communicationprotocols (e.g., HTTP, SNMP, and FTP). Each of the Monitor softwaremodules will be described in more detail below.

The following is a partial listing and description of the interfacesamong the Monitor modules discussed above. For example, some modules mayneed to have “init” functions or additional functions in order to obtainthe information in convenient formats.

void updateConfig(std::map<infoType, std::string> &)

Before this function is called, the calling function is preferred not toreplace the vendor and model entries if obtain functions return a nullstring. This function updates the device information database of thecurrent record in the DeviceODBC 1104. This function is most efficientwhen the ObtainConfig below is called initially. First, this functionchecks if the IP address is the same at the DeviceODBC 1104. If the IPaddress fields are not the same, the record with the correct IP addressis obtained from the database. Then, the other fields are copied and therecord is updated.

bool obtainConfig(std::map<infoType, std::string> &,std::map<std::string, std::vector<SParameter>> &)

This function obtains the map from DeviceODBC 1104 for the deviceinformation in the given format and the map of protocols and associatedparameters. The function returns true if there is data returned, falseif there is no more data.

bool saveStatus(std::map<infoType, std::string> &)

This function saves the status information into the DeviceODBC 1104. Thefunction returns true when saving is successful, false otherwise.

CDevice*createDevice(const std::string & in_sIP, CHWaccess &in_HWaccess, std::map<std::string, std::vector<SParameter>> &in_ProtocolParameters)

This function creates the device based upon in_sIP andin_ProtocolParameters. The created device is connected to the hardwarethrough CHWaccess. If the device can not be created, the functionreturns 0. Therefore, the calling object should check if the returnobject pointer is 0 or not.

bool canAccessHW(void)

This function returns true when the hardware can be accessed through thenetwork, false otherwise.

bool getVendor(std::string & out_sVendor)

This function returns the vendor name. If the device is not supported bythe system, but it can be accessed through one of the protocols, thestring shall contain “GENERIC.” If the error is detected in the process,the function returns false with null string. Otherwise, the functionreturns true.

bool getModel(std::string & out_sModel)

This function gets the model of the device. If the model is obtained,the function returns true. If the error is detected in the process, thefunction returns false with null string.

bool getUniqueID(std::string & out_sUniqueID)

This function returns the unique ID of the device. If the Unique ID isobtained, the function returns true. If the error is detected in theprocess, the function returns false with null string.

bool obtainStatus(map<infoType, std::string> & out_StatusMap)

This function returns the status map. The function returns true when thestatus is returned, false when status could not be obtained. Note thatthis function returns the different maps from the HWaccess and Devicemodules. In the Device module, event status information is added to themap returned from HWaccess and is cleared.

enum checkEventStatus(void)

This function triggers to obtain the event of the network device. Theenum type and values should be defined in the classes. The enum valuesshould include values eNoEventSinceClearAndNoEventDetected,eNoEventSinceClearAndEventDetected, eEventSinceClearAndNoEventDetected,eEventSinceClearAndEventDetected.

bool obtainEventStatus(std::map<infoType, std::string> &out_EventStatusMap)

This function obtains event status information. The function returnstrue when the status is returned, false when status could not beobtained.

void clearEventStatus(void)

This function clears the event status accumulated since the lastobtainStatus function call or clearEventStatus.

void initBegin(void)

This function starts the initialization process through HWaccess, inparticular, to create the software device objects.

void initEnd(void)

This function ends the initialization process through HWaccesssignifying that the device object creation is finished.

bool canAccessIP(const std::string & in_sIP, std::map<std::string,std::vector<SParameter>> & in_ProtocolParameters)

This function returns true when the device can be accessed at the IPaddress, false otherwise.

bool obtainVendor(std::string & out_sVendor, std::map<std::string,std::vector<SParameter>> & inOut_ProtocolParameters, const std::string &in_sIP)

This function obtains the Vendor. The function returns true if theoperation is successful, false with the empty string otherwise. Duringthis function call, the protocols are examined and if a particularprotocol can not be used for status monitoring, the protocol shall bedeleted from the inOut_ProtocolParameters.

bool obtainModel(std::string & out_sModelName, std::map<std::string,std::vector<SParameter>> & inOut_ProtocolParameters, const std::string &in_sIP)

This function obtains the Model name. The function returns true if theoperation is successful, false with the empty string otherwise. Duringthis function call, the protocols are examined, and if a particularprotocol can not be used for status monitoring, the protocol shall bedeleted from the inOut_ProtocolParameters.

bool obtainUniqueID(std::string & out_sUniqueID, std::map<std::string,std::vector<SParameter>> & inOut_ProtocolParameters, const std::string &in_sIP)

This function obtains the Unique ID. The function returns true if theoperation is successful, false with the empty string otherwise. Duringthis function call, the protocols are examined and if a particularprotocol can not be used for status monitoring, the protocol shall bedeleted from the inOut_ProtocolParameters.

EerrorCode obtainEventStatus(std::map<infoType, std::string> &out_StatusMap, const std::string & in_sIP, std::map<std::string,std::vector<SParameter>> & in_ProtocolParameters)

This function obtains the event status. The EerrorCode is defined below.

bool obtainStatus(std::map<infoType, std::string> & out_StatusMap, conststd::string & in_sIP, const std::string & in_sVendor, const std::string& in_sModel, std::map<std::string, std::vector<SParameter>> &in_ProtocolParameters)

This function obtains the status of the device. The function returnstrue if the operation is successful, false with the empty map otherwise.

FIG. 12 shows the sequence of the init( ) function to describe thecalling sequence of Monitor module 1006 as illustrated in FIG. 10. TheMonitorManager 1102 initializes the HWaccess module 1116 to start theinitialization function. Subsequently, the MonitorManager 1102 obtainsinformation about a monitored device and uses an IP address assigned tothe monitored device to communicate with the monitored device. TheMonitorManager 1102 accesses DeviceODBC 1104 to obtain configurationinformation of the monitored device. The configuration informationreturned to the MonitorManager 1102 includes, for example, an IP addressof the monitored device, parameter names and associated values for eachprotocol, and vendor/manufacturer and model information of the monitoreddevice. Once the IP address is obtained, the MonitorManager 1102 setsthe IP address, parameter names and associated values for each protocol,to create a software object for the device in the Device Module 1110.When the device software object is successfully created, the HWaccessmodule 1116 is used to obtain Vendor, Model, and Unique ID from themonitored device to be stored in the created device software object.

Once the vendor, model information, and unique ID are obtained from thedevice software object, the MonitorManager 1102 updates the database(for example, DeviceODBC 1104) with information received from themonitored device. Although FIG. 12 shows one device, the steps fromobtainConfig to updateConfig are repeated to cover all the devicesspecified in the external source. In addition, each protocol specifiedin FIGS. 21, 31, 32, and 33 are initialized. The database tablescorresponding to ODBC in FIGS. 21, 31, 32, and 33 are accessed andnecessary information for accessed devices are transferred from theexternal storage to the internal data structure so that the statusinformation collection from the accessed devices is faster.

FIG. 13 shows the sequence of the status monitor function to determinethe status of a monitored device by the MonitorManager module 1102, asillustrated in FIG. 11. When the obtainStatus function is issued fromDevice to HWaccess, the CHWaccess class in turn issues an obtainStatusfunction call to each protocol described in FIGS. 21, 31, 32, and 33through the abstract class, with different parameters, as describedbelow. Each protocol module has already cached information necessary toextract the status information from the monitored devices, which havealready been accessed once during the initialization time described inFIG. 12. Therefore, the status information can be quickly extracted fromthe monitored devices without accessing the external source during thestatus monitoring. This process is repeated over all the monitoreddevices stored in the vector as shown in FIG. 14.

Referring to FIG. 14, there is shown a vector 1500 having reference tothe devices created within the Device Module 1110 of FIG. 11 and used bythe MonitorManager 1102, as illustrated in FIGS. 12 and 13.MonitorManager 1102 stores device pointers, such as for example, Pointerto CDevice Object 1502, and Pointer to CDevice Object 1504 createdwithin the Device Module 1110, in the vector. The vector sequence isiterated to obtain the status of a monitored device. Polling ofmonitored devices is performed over the device object by issuing anobtainStatus command. Once the status of each of the software objects isobtained, such status is updated through the DeviceODBC 1104. The statusmonitor sequence was described above at FIG. 13, and will not berepeated herein.

The DeviceInfo structure shown in Table I illustrates the informationregarding one example monitored device. The DeviceInfo structureincludes the e-mail address of the contact person, in addition to thetelephone number.

TABLE 1 Type Name Description std::string m_sVendor A stringrepresenting the vendor of the network printer. std::string m_sModel Astring representing the model of the network printer. std::stringm_sUniqueID A string representing the Unique ID of the network printer.This ID may be a serial number or MAC Address or any unique ID ob-tainable from the network printer. std::string m_sIPAddress A stringrepresenting the IP address of the network printer. std::stringm_sCompanyName A string representing the name of the company which ownsthe network printer. std::string m_sStreet A string representing thestreet address of the company. std::string m_sCity A string representingthe city where the company is located. std::string m_sState A stringrepresenting the state where the company is located. std::stringm_sZipCode A string representing the zip code of the company.std::string m_sLocation A string representing the location of thenetwork printer within the company. std::string m_sContactPerson Astring representing the name of the contact person responsible for thenetwork printer. std::string m_sPhoneNumber A string representing thephone number of the contact person. std::string m_sEMailAddress A stringrepresenting the e-mail address of the contact person.Monitor Database

FIG. 17 illustrates the organization of the monitor database, whichincludes the device information for each monitored device (see alsoTable I). As shown in FIG. 17, a set of parameters, one set for eachcommunication protocol (e.g., SNMP, HTTP, and FTP), is associated withthe device information DeviceInfo 1902 for each monitored device.Moreover, each set of parameters for a particular protocol (e.g., SNMP1908, HTTP 1910, and FTP 1912) is organized as a list of parameter nameand value pairs, e.g., sPar1Name and sPar1Value. Note that the number ofparameters for each protocol may be shorter or longer than the numbershown in FIG. 17. For example, a username and password may be stored asFTP parameters, while a community name and a password may be stored asSNMP parameters for a given monitored device. As shown in FIG. 17, themonitor database also includes information related to the DeviceHistory1904, which contains the status information of the monitored devices,and the EnumCorrespondence 1906.

FIG. 15 illustrates the SParameter data structure 1700 used to pass theparameters used by the various communication protocols. SParameterincludes two fields: m_sParName 1702 and m_sParValue 1704, whichrepresent the name and value of the parameter, respectively.

FIG. 16 illustrates the map structure 1800 used to pass a vector ofparameters for each protocol obtained from the monitor database to asoftware object associated with each monitored device. The map structure1800 associates each protocol/key field 1802, 1804, and 1806, with acorresponding vector of parameters 1808, 1810, and 1812, respectively,arranged according to the SParameter format shown in FIG. 15. Forexample, for the SNMP protocol 1802, the vector of parameters 1808 mayinclude a list of parameter name, parameter value pairs that are used toaccess the monitored device with the SNMP protocol. For example, theSNMP parameter names stored in the vector 1808 might include “CommunityName” and “Password”, together with the corresponding parameter values.Note, however, that the organization of the map structure 1800 allowsfor any number of protocols and associated parameter vectors, and is notlimited to the SNMP, HTTP, and FTP protocols shown in FIG. 16.

Support Database

FIGS. 18-20 illustrate the organization of the support database 1024shown in FIG. 10. The support database, which includes informationnecessary to extract status information from each monitored device, isorganized by communication protocol. Moreover, the support databasecontains information for determining which protocols are supported by agiven vendor and model. For example, FIG. 18, which illustrates theorganization of the support database for SNMP-related supportinformation used to extract information from a monitored device,includes SNMPVendor 2002, SNMPComVendorStatus 2004, EnumCorrespondence2006, and SNMPVendorModelStatus 2008 data structures. A given datastructure in the support database may include parameters that uniquelyidentify the type of status information to be extracted, along withparameters that control the extraction. For example, theSNMPComVendorStatus data structure 2004 include an nENUM field 2009,which identifies the type of information to be extracted (e.g., tonerlevel), and an nRelativePriority field 2010, which indicates the weightor importance of the extracted information relative to other protocols.Thus, if the same information may be extracted from the monitored deviceusing more than one protocol, the nRelativePriority value gives arelative indication of which protocol's extracted value should be used.For example, if HTTP is only able to extract information indicatingwhether the toner level is “high” or “low” while the SNMP protocol isable to extract the percentage level of toner remaining, the prioritylevel for the toner level for SNMP would be higher than thecorresponding value for HTTP. In addition, the support database mayprovide default priority values for an entire protocol. In oneembodiment, the SNMP protocol is given a priority value of 10,000 in asystem in which protocol values may range from 0 to 32,000.

FIGS. 19 and 20 illustrate the data structures included in the HTTP andFTP portions of the support database 1024 and includes data structuresanalogous to the data structures described above with regard to FIG. 18.The EnumCorrespondence data structure shown in FIGS. 18-20 is shared bythe data structures for all of the protocols in the support database andis the same data structure shown in FIG. 17.

In FIG. 19, two sets of data structures are shown for using the HTTPprotocol to obtain information from the monitored devices. One set,which is labeled using the “Tag” prefix, provides support information toextract information located between tags in web pages of a monitoreddevice. The second set of data structures, which is labeled using the“Script” prefix, provides support information to extract informationcontained in Java scripts in web pages of a monitored device.

FIG. 20 shows data structures containing support information used toextract information from FTP files of a monitored device.

Exemplary enum types used by the present invention is the infoTypedefined below. (The enum types are merely exemplary and therefore shouldnot be construed as limiting the present invention.)

infoType (typedef int infoType)

This section describes the definition of the infoType (int). The valuerange 0 through 99 is assigned to the data type. The value range 100 to499 is assigned to Device Information. The value range 500 to 1999 isassigned to the common parameters including standard MIB parameters. Therange 2000 to 3999 is assigned to Ricoh-specific information. The range4000 to 4999 is assigned to Xerox. The range 5000 to 5999 is assigned toLexmark. The range 6000 to 6999 is assigned to HP. The values aredefined as follows:

infoType {eNotDefine=0, eDeviceInformation=1, eStatusInformation=2,eVendor=100, eModel, eUniqueID, eIPAddress, eCompanyName, eStreet,eCity, eState, eZipCode, eLocation, eContactPerson, ePhoneNumber,eEMailAddress, eDateTime=500, eHrDeviceErrors, eLowPaper, eNoPaper,eLowToner, eNoToner, eDoorOpen, eJammed, eOffline, eServiceRequested,ePrtGeneralConfigChanges=600, ePrtLifeCount, ePrtAlertDesc1,ePrtAlertDesc2, ePrtAlertDesc3, ePrtAlertDesc4, ePrtAlertDesc5,eBlack=700, eMagenta, eCyan, eYellow, eTonerCollector=800,eBlackDeveloper=810, eColorDeveloper, eFuser=820, eDrum=830,eTransfer=840, eMaintenanceKit=850, eOilKit=860, eStationInfo1=901,eStationInfo2, eStationInfo3, eStationInfo4, eStationInfo5,eRicohEngineCounterTotal=2000, eRicohEngineCounterPrinter,eRicohEngineCounterFax, eRicohEngineCounterCopier}.

EerrorCode

The following codes are merely exemplary, and more codes may be added tothe existing set. The range 0-99 is reserved. The range 100-199 is forSMTP, 200-299 is for POP3, 300-399 is for Socket, and 400-499 is forHTTP, and 500-599 is for FTP. Other ranges not specified may be definedby a user, if needed.

enum EerrorCode(eNoError=0, eUnknownError=1, eSomeError,eCompleteFailure, eSomeDeviceCreationError=20, eCreateDeviceError,eNoDeviceCreated, eObtainConfigError, eSaveStatusError,eObtainUniqueIDError, eObtainStatusError, eStartSendError,eSomeDataSendError, eCompleteDataSendFailure, eEndSendError,eSendHeloCommandFailed=100, eSendMailCommandFailed,eSendRcptCommandFailed, eSendDataCommandFailed, eSendDataFailed,eSendQuitCommandFailed, eSendUserCommandFailed=200,eSendPassCommandFailed, eSendStatCommandFailed, eSendRetrCommandFailed,eSendDeleCommandFailed, eSendQuitPop3CommandFailed,eCreateSocketFailed=300, eConnectSocketFailed, eBadRequest=400,eUnauthorized, ePaymentRequired, eForbidden, eNotFound,eMethodNotAllowed, eNotAcceptable, eProxyAuthenticationRequired,eRequestTimeOut, eConflict, eGone, eLengthRequired, ePreconditionFailed,eRequestEntityTooLarge, eRequestURITooLarge, eUnsupportedMediaType,eRequestedRangeNotSatisfiable, eExpectationFailed,eInternalServerError=450, eNotImplemented, eBadGateway,eServiceUnavailable, eGatewayTimeOut, eHTTPVersionNotSupported,eMultipleChoices=480, eMovedPermanently, eFound, eSeeOther,eNotModified, eUseProxy, eTemporaryRedirect).

Abstract Classes in the HWaccess Module

FIG. 21 shows the package diagram for the HWaccess package. This packageis responsible for identifying the network devices to be monitored andobtaining information about the network devices using various networkprotocols (e.g. SNMP, HTTP, and FTP). The package contains the packagesHTTP 2302, SNMP 2304, and FTP 2306 and the classes CHWaccess 2300,CAbsProtocol 2308, and CRecordSet 2310. The packages HTTP 2302, SNMP2304, and FTP 2306 implement the network protocols to access the networkdevices to obtain information from them. For example, the HTTP package2302 implement the HTTP protocol to access the web pages of the networkdevices to obtain information from the web pages. The class CHWaccess2300 manages all the protocol packages to obtain the necessaryinformation from the network devices. The class CAbsProtocol 2308 is anabstract class representing any protocol. This class provides theinterface between CHWaccess 2300 and the protocol packages. The classCAbsProtocol 2308 provides a set of common functions as shown in FIG. 21to CHWaccess 2300 in which all protocols will provide CHWaccess 2300 thenecessary information. The classes derived from CAbsProtocol 2308 asdescribed in later figures will provide the method for each of thefunctions for the appropriate protocols. The class CRecordSet 2310 is aclass of the Microsoft Foundation Class that provides each of theprotocol package access to the database to obtain information aboutwhich vendor and model of network devices are supported and whatinformation to obtain from those network devices. See Appendix 1 for theclass specification of CAbsProtcol.

Each of the protocol packages, HTTP 2302, SNMP 2304, and FTP 2306, asdescribed in FIG. 21, contain a class that manages the access to thenetwork device to obtain information from the device. The class isderived from the abstract class CAbsProtocol 2308 which provides for themethod of implementing the protocols to access information from thenetwork device. An abstract class only provides the interface functionsbut does not perform any process. The classes derived from the abstractclass provide the method to perform the process for the interfacefunctions. There can be many derived classes of the abstract class sothat the different derived classes can perform the process of theinterface function differently. For example, an interface function ofCAbsProtocol is obtainStatus( ). The derived class CSNMPProtocol shownin FIG. 31 will contain the function obtainStatus( ) which provides themethod to obtain the status information of a network device using SNMPwhile the derived class CHTTPProtocol shown in FIG. 33 will contain thefunction obtainStatus( ) which provides the method to obtain the statusinformation of a network device using HTTP. From the design of theHWaccess package, a new protocol can be added to the system by adding anew package that contains a derived class of CAbsProtocol that managesthe new package to access the network device using the new protocol. Theabstract class allows for the future expansion of the system.

FIG. 22 shows the data structure that is used in the HWaccess package ofFIG. 21 to maintain all the protocols to access and to obtaininformation from the network devices. In FIG. 22, the data structure isa vector 500 of pointers to CAbsProtocol 2308. The class CHWaccess 2300will contain and use this data structure. Even though the vector 500will contain pointers to classes derived from CAbsProtocol 2308,CHWaccess 2300 will see the vector as containing pointers toCAbsProtocol 2308 and call the interface functions of CAbsProtocol 2308through the virtual function call mechanism. In actuality, CHWaccess2300 will call the interface functions of the derived classes ofCAbsProtocol 2308. For example, the pointer to the CAbsProtocol 502 inthe first entry in the vector may be a pointer to the derived classCSNMPProtocol shown in FIG. 31, the pointer to the CAbsProtocol 504 inthe second entry in the vector may be a pointer to the derived classCHTTPProtocol shown in FIG. 33, and the pointer to the CAbsProtocol 506in the third entry in the vector may be a pointer to the derived classCFTPProtocol shown in FIG. 32. So when CHWaccess 2300 calls theinterface functions of CAbsProtocol 2308 in the vector, it is actuallycalling the interface functions of CSNMPProtocol, CHTTPProtocol, andCFTPProtocol. The use of the abstract class CAbsProtocol 2308 in thevector 500 allows any protocol to be used to access and obtaininformation from the network devices. The abstract class CAbsProtocol2308 hides the detail of what protocol is being used.

FIG. 23 is a sequence diagram that shows the initialization of theHWaccess package when init( ) of the Monitor package is called. All theprotocol objects will be created and initialized to access informationfrom the devices to be monitored. The calling of the function initBegin() of CHWaccess will create all the protocol objects (all derived fromCAbsProtocol). initBegin( ) of each protocol object will be called toinitialize its support information used to determine the vendor, model,and unique ID of the monitored devices. Before initEnd( ) of CHWaccessis called, functions of CHWaccess and the protocol objects will becalled to access the device and obtain and initialize vendor, model, andunique ID information of the device for all the protocols. By the timeinitEnd( ) of CHWaccess is called, each protocol object has all theinformation it needs to obtain the status information for the monitoreddevices which the protocol supports. initEnd( ) of each protocol objectwill clean up all the data structures it does not need after itsinitialization.

FIG. 24 is a sequence diagram that shows canAccessIP( ) of the HWaccesspackage to determine if the device is accessible by any protocol.CHWaccess will call canAccessIP( ) of each protocol object until one ofthe protocol objects can access the device corresponding to the IPaddress. If none of the protocol objects can access the device,canAccessIP( ) of CHWaccess returns false and the device will not bemonitored.

FIGS. 25A and 25B are two sequence diagrams that show two differentscenarios for obtaining the vendor, model, and unique ID of the devicefrom a protocol object and initializing the other protocol objects withvendor and model information. Once a protocol object obtains the vendorand model information of the device, the protocol object updates itssupport for the device so it can obtain status information from thedevice. The other protocol objects will need to receive informationabout the vendor and model of the device so they can update theirsupport for the device so they can obtain status information from thedevice. obtainVendor( ), obtainModel( ), and obtainUniqueID( ) ofCHWaccess are called in both FIGS. 25A and 25B. CHWaccess will use asmany of the protocol objects as necessary to obtain the vendor, model,and unique ID of the device and to initialize all the other protocolobjects with vendor and model information. CHWaccess will keep thevendor, model, and unique ID information for a given IP address of thedevice. In one scenario of FIG. 25A, CHWaccess callsobtainVendorModelUniqueID( ) of a protocol object and gets all theinformation from the protocol object. CHWaccess will then initialize allthe other protocol objects with the vendor and model information bycalling initWithVendorModel( ) of all the other protocol objects. Inanother scenario of FIG. 25B, CHWaccess calls obtainVendorModelUniqueID() of a protocol object and gets only the vendor from the protocolobject. Then CHWaccess calls obtainModel( ) and obtainUniqueID( ) ofanother protocol object to obtain the model and unique ID. CHWaccesswill then initialize all the other protocol objects with the vendor andmodel information by calling initWithVendorModel( ) of all the otherprotocol objects.

FIG. 26 shows a flowchart describing how the Protocol Parameter Map 1800of FIG. 16 is updated to determine which protocols are used to obtainthe status information from a network device. The steps in FIG. 26 areperformed to obtain the vendor name and the model name of a networkdevice for a protocol. In step 3702, a check is made to determine if thenetwork device can be accessed using a protocol. The network device isaccessed through the protocol using the information in the map 1800. Ifthe network device cannot be accessed through the protocol, the protocolis removed from the protocol parameter map 1800 in step 3704 and theupdating of the map 1800 is completed in step 3714. If the networkdevice can be accessed through the protocol, then in step 3706 a checkis made to determine if the vendor of the network device can be obtainedusing the protocol. If the vendor cannot be obtained, then in step 3707a check is made if GENERIC vendor is supported by the protocol. Supportfor GENERIC vendor for a protocol means that a protocol can obtainstatus information that is common to all devices (common statusinformation) even if it cannot obtain or does not support the vendor ofthe devices. If GENERIC vendor is not supported by the protocol, thenthe protocol is removed from the protocol parameter map 1800 in step3704 and the updating of the map 1800 is completed in step 3714. IfGENERIC vendor is supported by the protocol, then the protocol remainsin the protocol parameter map 1800 and the updating of the map iscompleted in step 3714. If the vendor can be obtained in step 3706, thenin step 3708 a check is made to determine if the vendor of the networkdevice is supported by the protocol. If the vendor is not supported bythe protocol, then in step 3707 a check is made if GENERIC vendor issupported by the protocol. The sequence of steps following step 3707 isdiscussed above.

If the vendor is supported by the protocol, then in step 3710 a check ismade to determine if the model of the network device can be obtainedusing the protocol. If the model cannot be obtained, then in step 3711 acheck is made if GENERIC model is supported by the protocol. Support forGENERIC model for a protocol means that a protocol can obtain statusinformation that is common to all devices of a vendor (vendor specificstatus information) even if it cannot obtain or does not support themodel of the devices. If GENERIC model is not supported by the protocol,then the protocol is removed from the protocol parameter map 1800 instep 3704 and the updating of the map 1800 is completed in step 3714. IfGENERIC model is supported by the protocol, then the protocol remains inthe protocol parameter map 1800 and the updating of the map is completedin step 3714. If the model can be obtained in step 3710, then in step3712 a check is made to determine if the model of the network device issupported by the protocol. If the model is not supported by theprotocol, then in step 3711 a check is made if GENERIC model issupported by the protocol. The sequence of steps following 3711 isdiscussed above. If the model is supported by the protocol, then theprotocol can be used to obtain status information for the network deviceand the updating of the protocol parameter map 1800 is completed in step3714. If the vendor and model are not obtained or not supported, thenthe protocol is removed from the protocol parameter map 1800 and theprotocol is not used to obtain status information. There are variationsto the process shown in FIG. 26 depending on the protocol. Whereas HTTPand FTP follow the description in the flowchart, SNMP will be supportedand used to obtain the status information even though the vendor issupported but the model and generic model are not supported.

As discussed above, status information can be obtained by SNMP from thenetwork device even if the vendor and model are not obtained orsupported. As long as the network device supports SNMP and can beaccessed by SNMP, information can be obtained from the ManagementInformation Base (MIB) of the network device. In step 3702, if thenetwork device cannot be accessed through SNMP, then the SNMP protocolmay be removed from the protocol parameter map 1800 in step 3704.However, if the network device can be accessed through SNMP, then theSNMP protocol remains in the protocol parameter map 1800 whether or notthe vendor or model is obtained and supported. Network devices thatsupport SNMP provide a MIB so that the remote system can always obtaininformation from the devices. However, the type and number ofinformation that can be obtained from the network device depends upon ifthe vendor and model are obtained and supported. More information can beobtained from the network device by SNMP is the vendor and model areobtained and known. If the vendor and model cannot be obtained, SNMP isstill able to obtain information that all devices can provide, such asthe system description or the time the system has been running. SNMP canbe used to obtain information from the network device under the threeconditions: (1) vendor and model are supported, (2) vendor supported butmodel not supported, and (3) vendor and model are not supported. HTTPand FTP do not have the characteristics as SNMP. Where SNMP has astandard MIB that all network devices can follow so that information canbe obtained, web pages and FTP files will vary among network devices ofdifferent vendors and models. There is no standard for web pages and FTPfiles which network devices follow to obtain information.

FIG. 27 shows a flowchart describing the process of obtaining statusinformation about the network devices using all the protocols. After theprotocol objects have been initialized with information about the vendorand model of network devices it supports as described in FIGS. 25A and25B, the protocol objects can be used to obtain status information fromthe network devices. The protocol objects contain information about howto obtain status information for given vendors and models using the datastructures containing information from the support database of FIGS. 18,19, and 20. The vector of pointers to CAbsProtocol 2308 described inFIG. 22 is used to obtain the status information for all the protocolobjects. The process of the flowchart will step through the vector once.In step 3122, a protocol object is obtained from the vector of pointersto CAbsProtocol. The protocol object corresponds to one of the networkprotocols to access the network device (e.g. SNMP, HTTP, and FTP). Instep 3124, a check is done to see if there are any more protocol objectsthat can be obtained from the vector. This check is done by determiningif the end of the vector has been reached. If no more protocol objectscan be obtained, then the system is done in obtaining the statusinformation from the network device using all the protocol objects instep 3126. If there is a protocol object obtained from the vector, thenuse the protocol object to obtain the status information of the networkdevice in step 3128. After obtaining the status information using theprotocol object, obtain more status information using another protocolobject by going back to step 3122.

FIG. 28 shows the data structure used to maintain the status informationobtained through the various protocols. It does not maintain informationabout which protocol was used to obtain the status information. The datastructure is a map 724. The key 726 to the map 724 is an infoType.infoType is a number representing a type of information. The value 728to the map 724 is a pair. The pair consists of a string and an integer.The string in the pair is the status information obtained from thenetwork device that corresponds to the infoType. The integer in the pairis the weight or priority of the status information as obtained from aprotocol. As an example, for the infoType of 700 that may represent thelevel of black toner in the printer cartridge, the pair may contain thestring “75%” and integer 10000. The string “75%” indicates that 75% ofthe toner remains in the cartridge and the integer 10000 is the weightor priority of the status information. CSNMPProtocol 2402, CHTTPProtocol2502, and CFTPProtocol 2602 adds status information that it obtains fromthe network devices to the map 724.

FIG. 29 shows the package diagram that is used within each of theprotocol packages of FIG. 21 wherein XXX is either SNMP, HTTP, or FTP.The abstract class CAbsProtocol provides the interface functions forobtaining information from the devices, but does not provide the methodto obtain the information. Classes derived from CAbsProtocol provide themethod which makes it convenient to add new protocols for obtaininginformation from devices. The CXXXProtocolImp1 class is the interfacefor the XXX package and manages all other classes/packages within thepackage. Since CXXXProtocolImp1 is derived from CAbsProtocol, this classprovides the method to obtain information from the devices for a givenprotocol. The XXXaccess package implements the protocol to access thedevice and to obtain information from the device. The XXXODBC packageobtains the protocol support information from the support database. Thisinformation includes the vendor and the model information the protocolsupports, how to obtain information about the vendor, model, and uniqueidentifier from the device, and how to obtain the status informationfrom the device. FIGS. 31 and 32 are specific uses of this packagediagram for SNMP and FTP. Any new protocols used to obtain statusinformation from the device will follow this structure for its packagediagram. One such new protocol can be web services. Also, differentimplementations of a protocol can follow this structure for its packagediagram.

FIG. 30 shows an alternative package diagram that can be used withineach of the protocol packages of FIG. 21 where again XXX is either SNMP,HTTP, or FTP. Even though this package diagram can be applied to any ofthe protocols, the HTTP protocol is used as an example as shown in FIG.33. This package structure allows for the extension of newimplementations of a protocol to obtain information from a device. Thisis necessary if the existing implementations of the protocols to obtaininformation do not work for new formats of the information, such as theexample web pages of FIGS. 40 and 42 which require anotherimplementation of HTTP. The abstract class CAbsProtocol is also used bythis package diagram as shown in FIG. 29. The CXXXProtocol class isderived from CAbsProtocol. CXXXProtocol provides an interface for theXXX package and manages all the classes corresponding to differentmethods in obtaining information from the devices.

The classes CXXXProtocolImp1 and CXXXProtocolImp2 implement twodifferent methods for obtaining information using the same protocol. TheCXXXProtocolImp1 class provides one implementation to obtain informationfrom a device and uses the packages XXXaccess1 and XXXODBC1. TheXXXaccess1 package implements the protocol to access the device and toobtain information from the device. The XXXODBC1 package obtains theprotocol support information from the database. This informationincludes the vendor and model that the protocol supports, how to obtaininformation the vendor, model, and unique identifier from the device,and how to obtain the status information from the device. TheCXXXProtocolImp2 class provides another implementation to obtaininformation from the device using the same protocol as CXXXProtocolImp1.CXXXProtocolImp2 uses the packages XXXaccess2 and XXXODBC2. TheXXXaccess2 package implements the protocol to access the device and toobtain information from the device. The XXXODBC2 package obtains theprotocol support information from the database just as XXXODBC1. Thedesign of this package allows for new implementations of the protocol.When a new implementation is needed, another implementation class willbe added along with its supporting package for accessing the deviceusing the protocol and obtaining information from the support database.Embodiments of the present system will work with the existingimplementations to obtain information from devices it already supportsalong with the new devices with the new implementation.

The package diagrams for SNMP and FTP follow the package structure ofFIG. 29 and are shown in FIG. 31 and FIG. 32. The package diagram forHTTP of this system follows the package structure of FIG. 30 and isshown in FIG. 33.

FIG. 31 shows the package diagram for a first embodiment of the SNMPpackage 2304. This package is responsible for determining the vendor andmodel of network devices supported by the SNMP protocol and theinformation to be obtained from the network devices by SNMP protocol,and for accessing the network device through the SNMP protocol to obtaininformation from the network devices. The package contains the packagesSNMPaccess and SNMPODBC and the class CSNMPProtocol and uses the classesCAbsProtocol 2400 and CRecordSet 2408 as described in FIG. 21. TheSNMPaccess package implements the SNMP protocol to access the networkdevices and to obtain information from the network devices. The SNMPODBCpackage accesses and obtains information from the database about vendorand model of network devices supported by the SNMP protocol and theinformation to be obtained from the network devices by SNMP protocol.The CSNMPProtocol class is a class derived from the CAbsProtocol class2400. CSNMPProtocol obtains the necessary information from the networkdevices using the SNMP protocol. CSNMPProtocol provides the method forall the interface functions of CAbsProtocol 2400 as described in FIG.21. FIG. 31 also shows the functions of the packages SNMPaccess andSNMPODBC that CSNMPProtocol uses. The SNMPODBC package uses the classCRecordSet to obtain information from the database.

FIG. 32 shows the package diagram for the FTP package 2306. This packageis responsible for determining the vendor and model of network devicessupported by the FTP protocol and the information to be obtained fromthe network devices by FTP protocol, and for accessing the networkdevices through the FTP protocol to obtain information from the networkdevices. The package contains the packages FTPaccess and FTPODBC and theclass CFTPProtocol and uses the classes CAbsProtocol 2600 and CRecordSet2608 as described in FIG. 21. The FTPaccess package implements the FTPprotocol to access the network devices and to obtain information fromthe network devices. The FTPODBC package accesses and obtainsinformation from the database about the vendor and the model of networkdevices supported by the FTP protocol and the information to be obtainedfrom the network devices by FTP protocol. The CFTPProtocol class is aclass derived from the CAbsProtocol class 2600. CFTPProtocol obtains thenecessary information from the network devices using the FTP protocol.CFTPProtocol provides the method for all the interface functions ofCAbsProtocol 2600 as described in FIG. 21. FIG. 32 also shows thefunctions of the packages FTPaccess and FTPODBC that CFTPProtocol uses.The FTPODBC package uses the class CRecordSet to obtain information fromthe database.

FIG. 33 shows a package diagram for the HTTP package, which is based onthe package diagram shown in FIG. 30. The package contains twoimplementations of HTTP to obtain information from the web pages. Thispackage uses the abstract class CAbsProtocol as describe in FIG. 21above. The CHTTPProtocol class is derived from CAbsProtocol.CHTTPProtocol is the interface for the HTTP package and manages thepackages corresponding to two different implementations of HTTP toobtain information from the devices. The TagHTTPImplementation packageis the implementation of HTTP to obtain information from between thetags of the web page of a device. The TagHTTPImplementation package wasdescribed as an embodiment of related U.S. patent application Ser. No.11/032,039, in which the package was called SecondHTTPImplementation.The TagHTTPImplementation package uses the TagHTTPODBC package to obtainsupport information from the database about the devices supported andhow to obtain the information from the devices. TheScriptHTTPImplementation package provides another implementation of HTTPto obtain information from within the java script of the web page of adevice, such as shown in FIGS. 40 and 42. The ScriptHTTPImplementationpackage uses the ScriptHTTPODBC package to obtain support informationfrom the database about the devices supported and how to obtain theinformation from the device. The second implementation of HTTP by theScriptHTTPImplementation package handles the problem of obtaininginformation from a device when the information is within the java scriptof the web page. HTTP_HTMLTool is shown as a package, but it is anamespace that contains objects that are used by the two implementationpackages. By using a namespace, the objects it contains can be usedwithin the HTTP package. This allows all the classes and packages ofHTTP to share the objects of the namespace. The HTTP package containsthe abstract class CAbsHTTPImplementation that provides the interfacefor obtaining information about the device by HTTP. Appendix 2 shows theclass specification for CAbsHTTPImplementation. Classes derived fromCAbsHTTPImplementation provide the method to actually obtain theinformation. The TagHTTPImplementation and ScriptHTTPImplementationpackages contain a class derived from CAbsHTTPImplementation thatdefines the method to obtain the information. The design of the HTTPpackage allows for future extension. If the current implementationscannot obtain information from the web pages of a device, then thedesign for a new implementation can be added by adding an implementationand the ODBC package.

In FIG. 34, the map structure m_ImplementationMap of the CHTTPProtocolclass is shown with sample entries. The key to the map structurem_ImplementationMap is a pointer to the CAbsHTTPImplementation class.Though the key is a pointer to the abstract classCAbsHTTPImplementation, the pointer will actually point to a derivedclass of CAbsHTTPImplementation. FIG. 34 shows two sample entries in themap corresponding to two derived classes of CAbsHTTPImplementation,CTagHTTPImplementation, and CScriptHTTPImplementation. The value to themap is a boolean indicating if the implementation class pointed to inthe key will be used. This map is initialized when the constructor ofCHTTPProtocol is called as the system starts up. The map is populatedwith all the different implementations of HTTP that obtains informationand its boolean value is set to false. During the discovery process(initialization) of determining which devices are being monitored, itwill be determined which implementations are needed. If animplementation is needed to obtain information from the devices, thenthe boolean value is set to true. After the discovery process iscompleted, if the boolean value corresponding to an implementation isfalse, the implementation is removed from the map.

In FIG. 35, the map structure m_VendorModelSupportMap of theCHTTPProtocol class is shown with sample entries. This map is used todetermine which implementations of HTTP to use to obtain information fora specific vendor and model of a monitored device. The key to the map isa string containing the concatenation of the vendor and model name. Thevalue corresponding to the key is a vector of pointers to the abstractclass CAbsHTTPImplementation. The pointers actually point to one of thederived classes of CAbsHTTPImplementation. The vector contains all theimplementations of HTTP to obtain status information for a vendor andmodel. The map m_VendorModelSupportMap is populated during the discoveryprocess (initialization) of the system.

In FIGS. 36A, 36B, and 36C, the sequence diagrams show the process forthe initWithVendor( ), initWithModel( ), and initWithVendorModel( )function of CHTTPProtocol. These functions initialize all theimplementations of the HTTP protocol so that each implementation willhave information to obtain status of a device of a specific vendor,specific model, or specific vendor and model. These functions are calledwhenever another protocol such as SNMP or FTP discovers the vendorand/or model of the device and the HTTP protocol object needs to beinitialized with the vendor and/or model to see if there is HTTP supportfor the device.

In FIG. 37, the flowchart shows the process of the functionobtainStatus( ) of CHTTPProtocol, which will use the mapm_VendorModelSupportMap. The process will determine if the input to thefunction contains the appropriate information to obtain the statusinformation. If not, then the function returns false. If the input tothe function contains the appropriate information, then the processdetermines if there is HTTP support for the vendor and model. If not,then the function returns false. If the vendor and model are supportedin HTTP, then all the implementations of HTTP that support the vendorand model will obtain the status information from the web pages of thedevice. If all the implementations of HTTP fail to obtain any statusinformation from the device, then the function returns false. Otherwise,the function returns true.

In FIG. 38, a package diagram is shown for the TagHTTPImplementationpackage. This package will implement HTTP to obtain information frombetween the tags of the web page of a device. The classCTagHTTPImplementation is the interface for this package and manages theother classes and packages to implement the method of obtaininginformation from between the tags of the web pages of a device.CTagHTTPImplementation is a class derived from CAbsHTTPImplementation.The TagHTTPODBC package and HTTP_HTMLTool package are describe abovewith regard to FIG. 33. The class CTagHTMLProcessor processes the webpage of a device to obtain the desired information. This class containsa method to process the text of the web pages of a specific format toobtain the desired information. More specifically, this class handlesweb pages in which the key word to locate the information occurs inmultiple places on the web pages.

FIG. 39 shows the map structure m_VendorModelWebInfoMap ofCTagHTTPImplementation, which is used by the tag implementation of HTTPto obtain status information of a device from the device's web pages.The key of the map is a string of the name of the vendor of the device.The value of the map is another map that contains information used toobtain status information from the device's web pages of a given model.The key of the inner map is a string for name of the model of the deviceand its value is a vector of structures, SWebPageInfo, containinginformation about the web pages and how to obtain status informationfrom the web pages. The structure SWebPageInfo contains the structureSPreconKeyValueInfo which provides all the information that is needed toobtain a single piece of information from a web page. The map structureis populated with information from the tables of the support databasefor the tag implementation of HTTP. The CTagHTTPImplementation uses theTagHTTPODBC package to obtain information from the tables of thedatabase.

FIG. 40 is a sample of a web page of a device for which the system willextract the status information. This sample web page uses java scriptwhich contains status information of the device.

In FIG. 41, part of the HTML source file is shown that results in theweb page being displayed in a browser as shown in FIG. 40. The fileshows both HTML tags and java scripts. Information about the differenttoner levels in found in the java script.

FIG. 42 shows another sample of a web page of a device for which thesystem will extract the status information. This sample web page alsouses java script which contains status information of the device.

In FIG. 43, part of the HTML source file is shown that results in theweb page being displayed in a browser as shown in FIG. 42. The fileshows both HTML tags and java scripts. Information about the black tonerlevel is found in the java script.

In FIG. 44, a package diagram is shown for the ScriptHTTPImplementationpackage. This package will implement HTTP to obtain information fromwithin the java scripts of the web page of a device such as shown inFIGS. 40 and 42. The class CScriptHTTPImplementation is the interfacefor this package and manages the other classes and packages to implementthe method of obtaining information from within the java script of theweb pages of a device. CScriptHTTPImplementation is a class derived fromCAbsHTTPImplementation. Appendix 3 shows the class specification ofCScriptHTTPImplementation. The ScriptHTTPODBC package and HTTP_HTMLToolpackage are describe above with regard to FIG. 33. The classCScriptHTMLProcessor processes the web page of a device to obtain onlythe java script from the web pages of a device. The classCAbsScriptProcess is an abstract class for processing the java script toobtain the status information. Appendix 4 shows the class specificationof CAbsScriptProcess. The class CAbsScriptProcess provides a set ofcommon functions to initialize the data structure used to obtaininformation from within the java script of a web page and to obtain theinformation from within the java script of the web page. The classesderived from CAbsScriptProcess will provide the method for each of thefunctions. The method depends upon the vendor, model, and web page ofthe device. There can be many derived classes of the abstract class sothat the different derived classes can perform the process of theinterface function differently. The abstract class allows for newdevices to be added in which the information exists within the javascript of the web pages.

In FIG. 45, the map structure m_VendorModelInfoMap ofCScriptHTTPImplementation is shown, which is used by the scriptimplementation of HTTP to obtain the model name of the device fromwithin the java script of the device's web page. The key of the map is astring for the name of the vendor of the device. The value of the map isa vector of the structure SModelInfo. The structure SModelInfo containsa string for the vendor name of the device, a string for the web page ofthe device which contains the model name, and a pointer to the abstractclass CAbsScriptProcess that will process the java script in the webpage to obtain the model name of the device. The pointer will point to aderived class of CAbsScriptProcess.

In FIG. 46, the map structure m_UniqueIDInfoMap ofCScriptHTTPImplementation is shown, which is used by the scriptimplementation of HTTP to obtain the unique identifier of the devicefrom within the java script of the device's web page. The uniqueidentifier is a string that identifies the device, e.g., the serialnumber or the MAC address. The key to the map is a string that is theconcatenation of the vendor and model name of the device. The value is astructure SUniqueIDInfo. The structure SUniqueIDInfo contains a stringfor the vendor name of the device, a string for the model name of thedevice, a string for the web page of the device which contains theunique identifier, and a pointer to the abstract class CAbsScriptProcessthat will process the java script in the web page to obtain the uniqueidentifier of the device. The pointer will point to a derived class ofCAbsScriptProcess.

In FIG. 47, the map structure m_StatusMap of CScriptHTTPImplementationis shown, which is used by the script implementation of HTTP to obtainthe status information of the device from within the java script of thedevice's web page. The key to the map is a string which is theconcatenation of the vendor and model name of the device. The value is avector of the structure SWebPageStatus. The structure SWebPageStatuscontains a string for the web page, a map structure of the statusinformation and its weight (priority) that can be obtained from the webpage, and a pointer to the abstract class CAbsScriptProcess that willprocess the java script in the web page to obtain the status informationof the device. The pointer will point to a derived class ofCAbsScriptProcess.

The three map structures are populated during the initialization of thesystem, i.e., the discovery process. All the derived classes ofCAbsScriptProcess are created and initialized during the initializationof the system. The derived classes are initialized with informationneeded to extract the desired information from the java script of a webpage. After the initialization of the system, only the map structurem_StatusMap is needed to periodically obtain status information from thedevices' web page. Therefore, the map structures m_VendorModelInfoMapand m_UniqueIDInfoMap are cleaned up after the initialization, sincethey are no longer needed.

In FIG. 48, a flowchart is shown describing the process of obtaining thestatus information by the ScriptHTTPImplementation package. The firststep tests if the IP address is empty. If the IP address is empty, thenthe process returns false. Otherwise, the method determines if thevendor and model name of the device is supported by the scriptimplementation of HTTP. If the vendor and model are not supported, thenthe process returns false. Otherwise the method obtains the delay usedto access the web pages of the device by HTTP. Next, an HTTP session isinitiated with the device. If the HTTP session cannot be initiated, thenthe process returns false. Otherwise, the process obtains all the webpages of the device for which the status information is contained withinthe java script of the web pages. For each web page, the process obtainsthe status information within the java script using the steps describedbelow. After obtaining the status information from the web pages, theprocess closes the HTTP session with the device. If no statusinformation was obtained from the device by the script implementation ofHTTP, then the process returns false. Otherwise, the process returnstrue.

In obtaining the status information from within a java script of a webpage, the process determines which status information needs to beobtained. This is done by checking the status information that hasalready been obtained by other protocols or by other implementations ofHTTP. If the status information to be obtained from the web page has notbeen obtained or has been obtained but has a lower weight (or priority),then the process obtains the status information. If all the statusinformation has already been obtained, then obtaining status informationfrom the web page is complete. Otherwise, the process initializes thescript processor to obtain status information. This initializationinvolves calling the start( ) function of CAbsScriptProcess. Then theprocess obtains the status information using the script processor.Obtaining the status information involves calling the transformData( )function of CAbsScriptProcess. FIG. 49 provides details of obtaining thestatus information using the transformData( ) function. After obtainingstatus information using the script processor, the process of obtainingstatus information from a web page is complete.

In FIG. 49, a flowchart is shown describing the process of obtaining thestatus information from within the script of a web page by theScriptHTTPImplementation package. First, the process attempts to accessthe web page using the HTTP session. If the web page cannot be accessed,then the process returns false. Otherwise, the process obtains a linefrom the web page. If a line is obtained from the web page, the processdetermines if the line is part of the java script. If not, then thesystem obtains the next line from the web page. Otherwise, the processuses the script processor to obtain the status information from the javascript. If the script processor does not obtain status information fromthe line of the java script, then the system obtains the next line fromthe web page. Otherwise, the process determines if the statusinformation obtained from the script processor is needed (the statusinformation may not be needed if it has already been obtained by anotherprotocol or by another implementation of HTTP with a weight greater thanor equal to that which was obtained by the script processor). If thestatus information is needed, then the process stores the statusinformation. The status information is put into the map structuredescribed in FIG. 28. After storing the status information or if thestatus information is not needed, the process determines if more statusinformation needs to be obtained from the java script of the web page.If more status information is needed to be obtained, the system obtainsthe next line from the web page. If there is no more status informationto be obtained or if there are no more lines that can be obtained fromthe web page, the process determines if there was any status informationobtained from within the java script. If no status information wasobtained, then the process returns false. Otherwise, the process returnstrue.

In FIG. 50, a class diagram is shown of the ScriptHTTPODBC package. Thispackage interfaces with the support database to obtain information usedto extract the model name, unique identifier, and status informationfrom within the java script of a web page of a device. TheCScriptHTTPODBC class is the interface for this package and manages theother classes to obtain the appropriate information from the tables ofthe support database. Appendix 5 shows the class specification ofCScriptHTTPODBC. The CXXXData classes and its corresponding CXXXTableclasses provide access to the XXX tables of the support database shownin FIG. 19 to obtain information from the tables. This package containsall the derived classes, CYYYScriptProcess, of CAbsScriptProcess thatwill be used to process the java scripts of the web pages of differentdevices. Each derived class provides methods to set the data structuresused to obtain the status information (putParameters( ) function), toinitialize the process to obtain the status information (start( )function), to obtain the status information from the java script(transformData( ) function), and to complete the process to obtain thestatus information (end( ) function). Adding new devices which aresupported by the script implementation of HTTP may require adding newclasses derived from CAbsScriptProcess for the devices. The functionsetupCreateFunctionMap( ) of CScriptHTTPODBC creates and sets the datastructures for all the derived classes of CAbsScriptProcess.

For FIG. 51, a state diagram is shown for processing the java script ofa web page of a device by derived classes of CAbsScriptProcess to obtaininformation. This state diagram corresponds to the transformData( )function of CAbsScriptProcess. Appendix 4 shows the class specificationof CAbsScriptProcess. There are two enums (enumerations) and onestructure defined in CAbsScriptProcess. The enum EReturn is used by thetransformData( ) function to return the results of the function inobtaining information from the java script of the web page of a device.The enum EState is used by the transformData( ) function to determinethe state of the process in obtaining the information from the javascript. Most of the states in the state diagram correspond to the enumEState. The structure SInfoStructure is used to obtain information fromthe java script of a web page. The derived classes of CAbsScriptProcessvary in its use of these enums and structure. Some derived classes mayuse only two values of the enum EReturn in transformData( ) whereas somederived classes may use all four. Some derived classes may use only twovalue of enum EState to obtain the desired information whereas somederived classes may use only three or four. Some derived classes maycontain an attribute member which is of type SInfoStructure to obtaininformation from the web page whereas some derived classes may containan attribute member which is a vector of SInfoStructure to obtainmultiple information from the web page.

In the state diagram, even though all five states corresponding to thevalue of enum EState are shown, not all will be used in obtaining thedesired information from the java script for all devices. The number ofstates and the number of m_sPar in the structure SInfoStructure used fortransitioning between the states depends upon the vendor, model, and webpage. The state diagram starts in state eStart. The process remains inthe eStart state until the string m_sPar1 of the struct SInfoStructureis found in the line of the java script. If the process corresponding tothe vendor, model, and web page only requires m_sPar1 to be found beforeextracting the data, then the next state is the Extraction state wherethe information is extracted from the line of the java script. Then theprocess is complete. Otherwise, the next state is ePrecon1. The processremains in the ePrecon1 state until the string m_sPar2 of the structSInfoStructure is found in the line of the java script. If the processcorresponds to a vendor, model, and web page that requires m_sPar2 to befound before extracting the data, then the next state is the Extractionstate where the information is extracted from the line of the javascript. Then the process is complete. Otherwise, the next state isePrecon2. The transitions for states ePrecon2 and ePrecon3 are similarto that of state ePrecon1 except the strings m_sPar3 and m_sPar4 of thestruct SInfoStructure causes the transitioning of states to occur. Whenthe process is in state ePrecon5, the process remains in the state untilm_sPar5 of structure SInfoStructure is found in the line of the javascript. The next state is the Extraction state and the process iscomplete. In obtaining information from the java script, five strings,m_sPar1 through m_sPar5, should be the most strings needed to obtain thedesired information.

FIG. 52 shows sample data structures used by two derived classes ofCAbsScriptProcess. The first derived class of CAbsScriptProcess,CSamsungStatusCLP550ScriptProcess, uses a vector of structSInfoStructure to obtain the color toner level from java script of theweb page of the device. Each toner level requires three strings m_sPar1through m_sPar3 to obtain the status information. Therefore, the processto obtain the information will go through three states—eStart, ePrecon1,and ePrecon2—before the status information will be extracted from thejava script. The second derived class,CSamsungStatusML2550ScriptProcess, uses the struct SInfoStructure byitself to obtain the black toner level from the java script of the webpage of the device. The toner level requires two strings m_sPar1 andm_sPar2 to obtain the black toner level. Therefore, the process toobtain the information will go through two states—eStart andePrecon1—before the black toner level will be extracted from the javascript. Appendices 6 and 7 show the class specification ofCSamsungStatusCLP550ScriptProcess and CSamsungStatusML2550ScriptProcess,respectively.

In FIG. 53, a sample web page is used to show how a derived class ofCAbsScriptProcess processes the web page of a device containing a javascript. The sample value of the struct SInfoStructure is shown below theweb page. In this example, the status information that is being obtainedis the cyan toner level. Three strings (parameters) m_sPar1, m_sPar2,and m_sPar3 of struct SInfoStructure, are needed to locate the statusinformation. The EState m_State of struct SInfoStructure is used to keeptrack of the strings that have been encountered. The delimiterm_sDelimiter of struct SInfoStructure and the position m_nInLinePositionof struct SInfoStructure are needed to extract the status informationfrom the line containing the status information. Each line of the webpage is read until all the status information is obtained or the end ofthe web page is encountered. Only the lines that are part of the javascript will be passed into transformData( ) of CAbsScriptProcess. Theinitial value of m_State of struct SInfoStructure is eStart. Lines ofthe java script are passed into transformData( ) of CAbsScriptProcess.When the line “function RemainTonerOption( )” is passed in, m_sPar1 ofstruct SInfoStructure is found in the line. m_State of structSInfoStructure is ePrecon1. More lines of the java script are passed inwith no changes to m_State. When the line “else” is passed in, m_sPar2of struct SInfoStructure is found in the line. m_State of structSInfoStructure is ePrecon2. More lines of the java script are passedwith no changes to m_State until the line “var CyanTonerPer=100” ispassed in. m_sPar3 of struct SInfoStructure is found in the line and thestatus information is extracted from the line using the valuesm_sDelimiter and m_nInLinePosition of struct SInfoStructure.m_sDelimiter are characters that delimit the status information andm_nInLinePosition is a number that determines how many delimiters occurbefore the status information is encountered. 0 for m_nInLinePosition iswhen the status information occurs before the first delimiter. A valueof “100” is obtained from the java script for the cyan toner level andno more lines of the web page needs to be obtained.

FIG. 54 is a flowchart showing the process of a derived class ofCAbsScriptProcess to extract information from the web page of a device.This flowchart is a sample process used to extract the cyan toner level,as described in FIG. 53. This process corresponds to transformData( ) ofCAbsScriptProcess. Though the method of transformData( ) of the derivedclasses of CAbsScriptProcess vary among vendors and models, the use ofstates to locate the status information is the common method to obtainthe status information.

FIG. 55A shows the members of the structure SInfoStructure that are usedto extract information from a web page. This structure is defined inCAbsScriptProcess shown in Appendix 4 and can be used by all the derivedclasses of CAbsScriptProcess. The strings m_sParXXX are used by thederived classes of CAbsScriptProcess to locate the line of the web pagethat contains the desired information. Not all the strings are needed tolocate the desired information, but having five strings m_sParXXXavailable allows flexibility for future devices that may require allfive strings to locate the desired information. The string m_sDelimiterand integer m_nInLinePosition are used to extract the desiredinformation from the line of the web page that contains it. The infoTypem_nENUM is a number representing the type of information to beextracted, such as eCyan, which represents the cyan toner level, orePrtLifeCount, which represents the total pages printed by the device.The EState m_State is used to keep track of the state of the structureas it locates the desired information from the web page. It isinitialized at the start state eState and changes state as each stringm_sParXXX is encountered.

Although the description and use of CAbsScriptProcess, its derivedclass, and its structure SInfoStructure has been focused on obtainingdata from within the script of the web page, the use of these structuresand methods can also be applied to obtaining data from between the tagsof the web page where the m_sParXXX may correspond to certain tags toobtain the data.

FIG. 55B shows the sample values of the member of the structureSInfoStructure of FIG. 55A. This structure is used to locate the cyantoner level (m_nENUM=eCyan) of the device from its web page. Only threestrings, m_sPar1 through m_sPar3, are needed to locate the desiredinformation. The remaining two strings, m_sPar4 and m_sPar5, are emptyand will not be used. The characters ‘=’ and ‘;’ of m_sDelimiter and 1for m_nInLinePosition will be used to extract the desired informationfrom the line where it exists.

Although the present invention is shown to include a few devices, whichrequire monitoring, connected to a network, it will be appreciated thatany number of devices may be connected to the network without deviatingfrom the spirit and scope of the invention. Also, the present inventionmay also be applied in a home environment wherein various devices needto be monitored and controlled.

Embodiments of the present invention enables the monitoring of thevarious devices in a multi-vendor environment and further facilitatesretrieving and displaying detailed information in a user-comprehensibleor user-friendly manner even without having specific private managementinformation base (MIB) information. Furthermore, the information can beredistributed using various methods such as SMTP, FTP, or Web Services.

The controller of the present invention may be conveniently implementedusing a conventional general purpose digital computer or amicroprocessor programmed according to the teachings of the presentspecification, as will be apparent to those skilled in the computer art.Appropriate software coding can readily be prepared by skilledprogrammers based on the teachings of the present disclosure, as will beapparent to those skilled in the software art. The invention may also beimplemented by the preparation of application specific integratedcircuits or by interconnecting an appropriate network of conventionalcomponent circuits, as will be readily apparent to those skilled in theart.

The present invention includes a computer program product residing on astorage medium including instructions that can be used to program acomputer to perform a process of the invention. The storage medium caninclude, but is not limited to, any type of disk including floppy disks,optical discs, CD-ROMs, and magneto-optical disks, ROMS, RAMs, EPROMs,EEPROMs, magnetic or optical cards, or any type of media suitable forstoring electronic instructions.

Numerous modifications and variations of the present invention arepossible in light of the above teachings. It is therefore to beunderstood that within the scope of the appended claims, the inventionmay be practiced otherwise than as specifically described herein.

APPENDIX 1 6.6.3 CAbsProtocol Class Specification 6.6.3.1 Base Class  None 6.6.3.2 Function List public:  CAbsProtocol( );  virtual~CAbsProtocol( );  virtual void initBegin(void) = 0;  virtual voidinitEnd(void) = 0;  virtual bool canAccessIP(const std::string&in_sIP,std::map<std::string, std::vector<SParameter> >& in_ProtocolParameters)= 0;  virtual bool obtainVendor(std::string&out_sVendor, std::map<std::string, std::vector<SParameter> >&inOut_ProtocolParameters, const std::string& in_sIP) = 0;  virtual boolobtainModel(std::string&out_sModelName,  std::map<std::string,std::vector<SParameter> >& inOut_ProtocolParameters, const std::string&in_sIP) = 0;  virtual bool obtainUniqueID(std::string&out_sUniqueID,std::map<std::string, std::vector<SParameter> >&inOut_ProtocolParameters, const std::string& in_sIP) = 0;  virtualEerrorCode obtainEventStatus(std::map<infoType, std::pair<std::string,int> >& inOut_StatusMap, const std::string&in_sIP, std::map<std::string,std::vector<SParameter> >& in_ProtocolParameters) = 0;  virtual boolobtainStatus(std::map<infoType, std::pair<std::string,int> >&inOut_StatusMap, const std::string&in_sIP, conststd::string&in_sVendor, const std::string&in_sModel,std::map<std::string, std::vector<SParameter> > & in_ProtocolParameters)= 0;  virtual void initWithVendor(std::map<std::string,std::vector<SParameter> >& inOut_ProtocolParameters, const std::string&in_sVendor) = 0;  virtual void initWithModel(std::map<std::string,std::vector<SParameter> >& inOut_ProtocolParameters, const std::string&in_sModel) = 0;  virtual void initWithVendorModel(std::map<std::string,std::vector<SParameter> >& inOut_ProtocolParameters, const std::string &in_sVendor, const std::string & in_sModel) = 0;  virtualCAbsProtocol::EStatus obtainVendorModelUniqueID(std::string&out_sVendor, std::string &out_sModel, std::string &out_sUniqueID,std::map<std::string, std::vector<SParameter> >&inOut_ProtocolParameters, const std::string & in_sIP) = 0; 6.6.3.3Defined Type List public:  enum EStatus {    eAll = 0,    eVendorModel,   eVendorUniqueID,    eModelUniqueID,    eVendorOnly,    eModelOnly,   eUniqueIDOnly,    eNone  }; 6.6.3.4 Class Attributes   None 6.6.3.5Function Definitions/////////////////////////////////////////////////////////////////////////Function:   CAbsProtocol( ) // Description: Constructor //Preconditions:  None. // Postconditions:  None. // Algorithm:  Default.///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Function:   CAbsProtocol( ) // Description: Destructor // Preconditions: None. // Postconditions:  None. // Algorithm: Default.//////////////////////////////////////////////////////////////////////

APPENDIX 2 6.6.5.5 CAbsHTTPImplementation Class Specification 6.6.5.5.1Base Class   None 6.6.5.5.2 Function List public: CAbsHTTPImplementation( );  virtual ~CAbsHTTPImplementation( ); virtual void initBegin(void) = 0;  virtual void initEnd(void) = 0; virtual bool obtainVendor(std::string &out_sVendor,std::map<std::string, std::vector<SParameter> > &inOut_ProtocolParameters, const std::string & in_sIP) = 0;  virtual boolobtainModel(std::string &out_sModel, std::map<std::string,std::vector<SParameter> > & inOut_ProtocolParameters, const std::string& in_sIP) = 0;  virtual bool obtainUniqueID(std::string &out_sUniqueID,std::map<std::string, std::vector<SParameter> > &inOut_ProtocolParameters, const std::string & in_sIP) = 0;  virtual boolobtainModelWith Vendor(std::string &out_sModel, std::map<std::string,std::vector<SParameter> > & inOut_ProtocolParameters, const std::string& in_sVendor) = 0;  virtual bool obtainVendorWithModel(std::string&out_sVendor, std::map<std::string, std::vector<SParameter> > &inOut_ProtocolParameters, const std::string & in_sModel) = 0;  virtualbool initWithVendorModel(std::map<std::string, std::vector<SParameter> >& inOut_ProtocolParameters, const std::string & in_sVendor, conststd::string & in_sModel) = 0;  virtual boolobtainStatus(std::map<infoType, std::pair<std::string, int> >&inOut_Data, const std::string &in_sIP, const std::string &in_sVendor,const std::string &in_sModel, std::vector<SParameter> & in_Parameter) =0;  virtual void currentVendorModelForIP(const std::string&in_sVendor,const std::string & in_sModel, const std::string & in_sIP)=0; 6.6.5.5.3Defined Type List   None 6.6.5.5.4 Class Attributes   None 6.6.5.5.5Function Definitions/////////////////////////////////////////////////////////////////////////Function:  CAbsHTTPImplementation( ) // Description: Constructor //Preconditions: None. // Postconditions: None. // Algorithm: Default.////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Function:  ~CAbsHTTPImplementation( ) // Description: Destructor //Preconditions: None. // Postconditions: None. // Algorithm: Default.///////////////////////////////////////////////////////////////////////

APPENDIX 3 6.6.5.6.2 CScriptHTTPImplementation Class Specification  Add. h files that contain the HTTP_HTMLTool namespace definition andCAbsScriptProcess declaration. 6.6.5.6.2.1 Base Class  publicCAbsHTTPImplementation 6.6.5.6.2.2 Function List public: CScriptHTTPImplementation( );  ~CScriptHTTPImplementation( );  virtualvoid initBegin(void);  virtual void initEnd(void);  virtual boolobtainVendor(std::string &out_sVendor, std::map<std::string,std::vector<SParameter> > & inOut_ProtocolParameters, const std::string& in_sIP);  virtual bool obtainModel(std::string &out_sModel,std::map<std::string, std::vector<SParameter> > &inOut_ProtocolParameters, const std::string & in_sIP);  virtual boolobtainUniqueID(std::string &out_sUniqueID, std::map<std::string,std::vector<SParameter> > & inOut_ProtocolParameters, const std::string& in_sIP) ;  virtual bool obtainModelWithVendor(std::string &out_sModel,std::map<std::string, std::vector<SParameter> >&inOut_ProtocolParameters, const std::string & in_sVendor) ;  virtualbool obtainVendorWithModel(std::string &out_sVendor,std::map<std::string, std::vector<SParameter> >&inOut_ProtocolParameters, const std::string & in_sModel) ;  virtualbool initWithVendorModel(std::map<std::string, std::vector<SParameter> >& inOut_ProtocolParameters, const std::string & in_sVendor conststd::string & in_sModel);  virtual bool obtainStatus(std::map<infoType,std::pair<std::string, int> > &inOut_Data, const std::string &in_sIP,const std::string &in_sVendor, const std::string &in_sModel,std::vector<SParameter> & in_Parameter);  virtual voidcurrentVendorModelForIP(const std::string &in_sVendor, const std::string& in_sModel, const std::string & in_sIP); private:  boolobtainDeviceInfo(const std::string& in_sIP, std::vector<SParameter> &in_Parameter);  void updateStatusMap(const std::string& in_sVendor,const std::string& in_sModel);  void selectEntries(std::map<infoType,int> &out_InfoTypeMap, std::map<infoType, std::pair<std::string, int> >&in_StatusMap, std::map<infoType, int> & in_InfoTypeMap);  boolobtainSupportedModel(std::string&out_sModel, conststd::string&in_sModelString, const std::string& in_sVendor);  boolinitiateHTTP(const std::string &in_sIP, std::vector<SParameter>&in_Parameter, int in_nDelay = HTTPDefaultDelay);  boolobtainDataFromHTMLFile(std::map<infoType, std::pair<std::string,int> >&inOut_Data, const std::string &in_sWebPage, std::map<infoType, int>&in_InfoTypeMap, CAbsScriptProcess * in_pScriptProcess);  boolcloseHTTP( ); 6.6.5.6.2.3 Defined Type List private:  structSWebPageStatus {    std::string m_sWebPage;    std::map<infoType, int>m_InfoTypeMap;    CAbsScriptProcess * m_pScriptProcess;   };  structSModelInfo {    std::string  m_sVendor;    std::string m_sWebPage;   CAbsScriptProcess *  m_pScriptProcess;   };  struct SUniqueIDInfo{   std::string  m_sVendor;    std::string  m_sModel;    std::string m_sWebPage;    CAbsScriptProcess * m_pScriptProcess;  }; 6.6.5.6.2.4Class Attributes private: Type Attribute Name DescriptionCScriptHTMLProcessor m_ScriptHTMLProcessor This attribute memberprovides HTML processing. CScriptHTTPODBC * m_pHTTPODBC This attributemember is created in initBegin and destroyed in initEndstd::map<std::string, int> m_DelayedMap This first entry of the map isVendor + model and the second entry is delay. std::map<std::string,m_StatusMap This entry contains the key of std::vector<SWebPageStatus> >Vendor + Model string and vector of SWebPageStatus structure used toobtain the status std::map<std::string, m_VendorModelSupportMap Thisentry contains the key of vendor std::vector<std::string> > and thevalue of vector of models. std::map<std::string,m_ModelVenderorSupportMap This entry contains the key of modelstd::vector<std::string> > and the value of vector of vendors.std::map<std::string, m_VendorModelInfoMap This map contains informationof how std::vector<SModelInfo> > to get the model for the given vendorin the key. std::map<std::string, m_UniqueIDInfoMap This map containskey of SUniqueIDInfo > Vendor + Model and structure to obtain the uniqueID. std::map<CAbsScriptProcess m_InitAbsScriptProcessMap This map keepstrack of the addresses *, int functions to get models and unique ID'sstd::map<CAbsScriptProcess m_StatusAbsScriptProcessMap This map keepstrack of the addresses *, int functions to get status.std::vector<std::string> m_ModelIter This attribute is used to iterateover ::iterator the vector of models in m_VendorModelSupportMap. This isused by obtainModelWithVendor( ). std::vector<std::string> m_VendorIterThis attribute is used to iterate over ::iterator the vector of vendorsin m_ModelVendorSupportMap. This is used by obtainVendorWithModel( )std::string m_sCachedIP This attribute member contains the cached IPaddress. std::string m_sCachedVendor This attribute member contains thevendor obtained corresponding to the Cached IP address. std::stringm_sCachedModel This attribute member contains the model obtainedcorresponding to the Cached IP address. std::string m_sCurrentVendorThis attribute member contains the vendor used by obtainModelWithVendor(). std::string m_sCurrentModel This attribute member contains the modelused by obtainVendorWithModel( ). std::vector<SParameter>m_ParameterVector This attribute is a place holder for the future use ofthe parameters.

APPENDIX 4 6.6.5.6.5 CAbsScriptProcess Class Specification 6.6.5.6.5.1Base Class  None 6.6.5.6.5.2 Function List public:  CAbsScriptProcess();  virtual ~CAbsScriptProcess( );  virtual void start(void) = 0; virtual CAbsScriptProcess::EReturn transformData(std::string&out_sValue, infoType & out_nInfoType, const std::string in_sString) =0;  virtual void putParameters(std::vector<std::string>in_ParameterVector, const infoType in_InfoType)=0;  virtual boolend(std::string & out_sValue, infoType & out_nInfoType); 6.6.5.6.5.3Defined Type List public:  enum EReturn{    eWithValueMoreValues = 0,   eWithValueNoMoreValue,    eNoValue,    eFinished  }; protected:  enumEState{   eStart = 0,   ePrecon1,   ePrecon2,   ePrecon3,   ePrecon4  }; struct SInfoStructure {   std::string m_sPar1;   std::string m_sPar2;  std::string m_sPar3;   std::string m_sPar4;   std::string m_sPar5;  std::string m_sDelimiter;   int m_nInlinePosition;   infoType m_nENUM;  EState m_State;   SInfoStructure( );   ~SInfoStructure( );   voidinit( );  }; 6.6.5.6.5.4 Class Attributes     None 6.6.5.6.5.5 FunctionDefinitions//////////////////////////////////////////////////////////////////////////// Function: CAbsScriptProcess( ) // Description: Constructor //Preconditions:  None. // Postconditions:  None. // Algorithm: Default./////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: ~CAbsScriptProcess( ) // Description: Destructor //Preconditions:  None. // Postconditions:  None. // Algorithm: Default.//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: end(std::string &out_sValue, infoType & //  in_infoType) //Description:  This function perform the final processing of data // after the last call to transformData( ). This //  function will returntrue, a data string, and an //  infoType if there is any final data toreturn. //  This function does nothing but returns false, //  an emptydata string, and eNotDefine for the //  infoType. The derived classescan override this //  function. // Preconditions:  None. //Postconditions:  None. // Algorithm: 1. clear out_sValue and setout_nInfoType to //  eNotDefine. //  2. return false.//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: SInfoStructure::SInfoStructure( ) // Description:Constructor // Preconditions:  None. // Postconditions:  None. //Algorithm: 1 calls init( )//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: SInfoStructure::~SInfoStructure( ) // Description:Destructor // Preconditions:  None. // Postconditions:  None. //Algorithm: Default.////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////Function:  SInfoStructure::init( ) // Description: This functioninitializes the attribute members of //  SInfoStructure. //Preconditions:  None. // Postconditions:  None. // Algorithm: 1 set allthe strings to null //  2 set m_nInlinePosition to −1 //  3 set m_Stateto eStart //  4 set m_nENUM to eNotDefine.///////////////////////////////////////////////////////////////////////

APPENDIX 5 6.6.5.6.5.2 CScriptHTTPODBC Class Specification   This classrequires    typedef CAbsScriptProcess * (*createScriptProcess)(void);before using createScriptProcess as a type. Also, the followingfunctions should be declared on the top of .cpp file as globalfunctions.  CAbsScriptProcess * createSamsungPrinterDetail(void); CAbsScriptProcess * createSamsungStatusCLP550(void); CAbsScriptProcess * createSamsungStatusML2550(void); CAbsScriptProcess * createKyoceraModel(void);  CAbsScriptProcess *createKyoceraUniqueID(void);  CAbsScriptProcess *createKyoceraFS3830(void); All the objects created by this class are notdestroyed in this class. The calling class should manage the objectdestruction. 6.6.5.6.5.2.1 Base Class   None 6.6.5.6.5.2.2 Function Listpublic:  CScriptHTTPODBC( );  ~CScriptHTTPODBC( );  void init( );  boolobtainScriptSupportVendorModel(std::string& out_sVendor, std::string&out_sModel);  bool obtainHTTPDelay(int&out_nDelay, conststd::string&in_sVendor, const std::string& in_sModel);  boolobtainScriptModelForVendor(std::string &out_sVendor, std::string&out_sWebPage, CAbsScriptProcess *& out_pAbsScriptProcess);  boolobtainScriptUniqueID(std::string &out_sVendor, std::string &out_sModel,std::string & out_sWebPage, CAbsScriptProcess *& out_pAbsScriptProcess); bool obtainScriptStatus(std::string&out_sWebPage, std::map<infoType,int> &out_InfoTypeMap, CAbsScriptProcess *&out_pAbsScriptProcess, conststd::string&in_sVendor, const std::string& in_sModel); private:  voidsetupCreateFunctionMap(void);  bool extractVendorModel (std::string&out_sVendor, std::string &out_sModel, const std::string & in_sString);6.6.5.6.5.2.3 Defined Type List private:  structSWebPageCreateScriptProcess {    std::string  m_sWebPage;    int  m_nWebPageID;    std::map<infoType, int> m_InfoTypeWeightMap;   createScriptProcess  m_createScriptProcess;    CAbsScriptProcess * m_pScriptProcess;  }; 6.6.5.6.5.2.4 Class Attributes private: TypeAttribute Name Description CScriptVendorModelData m_VendorModelData Thisattribute member accesses the database table containing information usedto obtain the model of the device. CHTTPSupportedVendorModelm_VendorModelDelayData This attribute member accesses the databaseDelayData table containing information about the vendor and model of thedevice supported and the delay associated with itCScriptUniqueIDWebPageData m_UniqueIDWebPageData This attribute memberaccesses the database table containing information used to obtain theunique ID of the device. CscriptVendorModelWeb m_VendorModelWeb Thisattribute member accesses the database PageData PageData tablecontaining information about the web pages of the device that containstatus information. CScriptStatusData m_ScriptStatusData This attributemember accesses the database table containing information used to obtainthe status information from the web pages the device.std::map<std::string, m_ModelCreateScript This attribute member containscreateScriptProcess> ProcessMap createScriptProcess functions forobtaining the model corresponding to the key of a vendorstd::map<std::string, m_UniqueIDCreateScript This attribute membercontains createScriptProcess> ProcessMap createScriptProcess functionfor obtaining the Unique ID corresponding to the key of Vendor +separator + Model std::map<std::string, m_StatusCreateScript Thisattribute member contains a vector of std::vector< ProcessMapSWebPageCreateScriptProcess SWebPageCreateScriptProcess> > correspondingto the key of Vendor + separator + Model std::map<std::string, int>m_VendorModelDelayMap This attribute member contains a delaycorresponding to the key of Vendor + separator + Modelstd::map<std::string, m_StatusCreateScript This attribute is used toiterate std::vector< ProcessMapItr m_StatusCreateScriptProcessMap usedin the SWebPageCreateScriptProcess> > functionobtainScriptSupportVendorModel ::iterator std::vector<m_WebPageScriptProc This attribute member keepsSWebPageCreateScriptProcess> VectorItr SWebPageCreateScriptProcessvector used ::iterator in the function obtainScriptStatus( ).std::string m_sCachedCombine This attribute member tracks if the callhas the same Vendor and Model or not.

APPENDIX 6 6.6.5.6.5.14 CSamsungStatusCLP550ScriptProcess ClassSpecification   This process extracts the toner status from SamsungCLP550 printers.   The data is located in the web page, /panel/setup.htmin the following format. function RemainTonerOption( ) {  if((modelVer!= 0x0701)&&(modelVer != 0x0702)&&(modelVer != 0x0703)&&(modelVer !=0x0711))  {   document.write(‘<tr><td width=“10” height=“35”></td><tdwidth=“263” height=“35”><font size=“2” face=“Arial”>Remain Toner:(0%)</font></td>’);   document.write(‘<td width=“381” height=“35”colspan=“2”><table border=“1” width=“300” cellspacing=“0”cellpadding=“0”><tr><td width=“300” height=“17”>’);  document.write(‘<table border=“0” height=“100%” width=“300”cellspacing=“0” cellpadding=“0”><tr>’);   document.write(‘<td width=“15”bgcolor=“#FFFFFF”></td><td width=“15” bgcolor=“#FFFFFF”><td>’);  document.write(‘<td width=“15” bgcolor=“#FFFFFF”></td><td width=“15”bgcolor=“#FFFFFF”></td>’);   document.write(‘<td width=“15”bgcolor=“#FFFFFF”></td><td width=“15” bgcolor=“#FFFFFF”></td>’);  document.write(‘<td width=“15” bgcolor=“#FFFFFF”></td><td width=“15”bgcolor=“#FFFFFF”></td>’);   document.write(‘<td width=“15”bgcolor=“#FFFFFF”></td><td width=“15” bgcolor=“#FFFFFF”></td>’);  document.write(‘<td width=“15” bgcolor=“#FFFFFF”></td><td width=“15”bgcolor=“#FFFFFF”></td>’);   document.write(‘<td width=“15”bgcolor=“#FFFFFF”></td><td width=“15” bgcolor=“#FFFFFF”></td>’);  document.write(‘<td width=“15” bgcolor=“#FFFFFF”></td><td width=“15”bgcolor=“#FFFFFF”></td>’);   document.write(‘<td width=“15”bgcolor=“#FFFFFF”></td><td width=“15” bgcolor=“#FFFFFF”></td>’);  document.write(‘<td width=“15” bgcolor=“#FFFFFF”></td><td width=“15”bgcolor=“#FFFFFF”></td>’);  document.write(‘</tr></table></td></tr></table><table border=“0”width=“300” cellspacing=“0” cellpadding=“0”>’);  document.write(‘<tr><td width=“100”><font face=“Arial”size=“2”>0%</font></td>’);   document.write(‘<td width=“100”align=“center”><font face=“Arial” size=“2”>50%</font></td>’);  document.write(‘<td width=“100” align=“right”><font face=“Arial”size=“2”>100%</font></td></tr></table></td></tr>’);  }  else  {   varCyanTonerPer = 100;   var MagentaTonerPer = 100;   var YellowTonerPer =100;   var BlackTonerPer = 100;   BeforeTonerPerOption(“Cyan”);  document.write(‘<font size=“2”face=“Arial”>(‘+CyanTonerPer+’%)</font>’);   BeforeRemainTonerOption( );  DisplayReminedToner(CyanTonerPer,“#00FFFF”);   AfterRemainTonerOption();   BeforeTonerPerOption(“Magenta”);   document.write(‘<font size=“2”face=“Arial”>(‘+MagentaTonerPer+’%)</font>’);   BeforeRemainTonerOption();   DisplayReminedToner(MagentaTonerPer,“#FF00FF”);  AfterRemainTonerOption( );   BeforeTonerPerOption(“Yellow”);  document.write(‘<font size=“2”face=“Arial”>(‘+YellowTonerPer+’%)</font>’);   BeforeRemainTonerOption();   DisplayReminedToner(YellowTonerPer,“#FFFF00”);  AfterRemainTonerOption( );   BeforeTonerPerOption(“Black”);  document.write(‘<font size=“2”face=“Arial”>(‘+BlackTonerPer+’%)</font>’);   BeforeRemainTonerOption();   DisplayReminedToner(BlackTonerPer,“#000000”);  AfterRemainTonerOption( );  } } . . sDelimiter = “=;”, nInlinePosition=1 , sPar1 = “RemainTonerOption”, sPar2 = “else”, sPar3 = “varCyanTonerPer”, nENUM = eCyan sDelimiter = “=;”, nInlinePosition =1 ,sPar1 = “RemainTonerOption”, sPar2 = “else”, sPar3 = “varMagentaTonerPer”, nENUM = eMagenta sDelimiter = “=;”, nInlinePosition =1, sPar1 = “RemainTonerOption”, sPar2 = “else”, sPar3 = “varYellowTonerPer”, nENUM = eYellow sDelimiter = “=;”, nInlinePosition =1 ,sPar1 = “RemainTonerOption”, sPar2 = “else”, sPar3 = “varBlackTonerPer”, nENUM = eBlack 6.6.5.6.5.14.1 Base Class  publicCAbsScriptProcess 6.6.5.6.5.14.2 Function List public: CSamsungStatusCLP550ScriptProcess( );  virtual~CSamsungStatusCLP550ScriptProcess( );  virtual void start(void); virtual CAbsScriptProcess::EReturn transformData(std::string&out_sValue, infoType & out_nInfoType, const std::string in_sString); virtual void putParameters(std::vector<std::string> in_ParameterVector,const infoType in_InfoType); 6.6.5.6.5.14.3 Defined Type List   None6.6.5.6.5.14.4 Class Attributes private: Type Attribute Name Descriptionstd::vector<SInfoStructure> m_InfoStructureVector This attribute keepsthe vector of information used to extract the status informationstd::vector<SInfoStructure> m_InfoStructureSearchVector This attributeis used to extract the information. As the value is obtained, the entryis deleted from the vector. start( ) function copies the entries fromm_InfoStructureVector. 6.6.5.6.5.14.5 Function Definitions/////////////////////////////////////////////////////////////////////////Function:   CSamsungStatusCLP550ScriptProcess( ) // Description:Constructor // Preconditions:  None. // Postconditions:  None. //Algorithm: 1 default//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: ~CSamsungStatusCLP550ScriptProcess( ) // Description:Destructor // Preconditions:  None. // Postconditions:  None. //Algorithm: 1 default//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: start(void) // Description: This function copies them_InfoStructureVector to //  m_InfoStructureSearchVector. //Preconditions:  None // Postconditions:  None // Algorithm: 1m_InfoStructureSearchVector = //  m_InfoStructureVector//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: transformData(std::string &out_sValue, infoType & //  out_nInfoType, const std::string in_sString) // Description: Thisfunction processes the input string to //  extract the value and itscorresponding infoType. // Preconditions:  None. // Postconditions: None. // Algorithm: 1 set out_sValue to Null and out_nInfoType to //  eNotDefine //  2 if m_InfoStructureSearchVector is empty, //   returneFinished //  3 declare iterator loc_Itr of //  m_InfoStructureSearchVector and set to //   m_InfoStructureSearchVector.begin( ) //  4 while loc_Itr < //  m_InfoStructureSearchVector.end( ) //   4.1 switch on(*loc_Itr).m_State //   4.1.1 case eStart: //    4.1.1.1 if(*loc_Itr).m_sPar1 is found in //    in_sString, (*loc_Itr).m_State =ePrecon1 //    4.1.1.2 increment loc_Itr //    4.1.1.3 break //   4.1.2case ePrecon1: //    4.1.2.1 if (*loc_Itr).m_sPar2 is found in //   in_sString, (*loc_Itr).m_State = ePrecon2 //    4.1.2.2 incrementloc_Itr //    4.1.2.3 break //   4.1.3 case ePrecon2: //    4.1.3.1 if(*loc_Itr).m_sPar3 is not found //     in in_sString, //     4.1.3.1.1increment loc_Itr //     4.1.3.1.2 break //    4.1.3.2 usingCExtractValueFromLine, if //     operator( ) with out_sValue, //    m_sDelimiter, m_nInlinePosition of the //     iterator andin_sString passed //     in returns false, //    4.1.3.2.1 ASSERT //   4.1.3.2.2 increment loc_Itr //    4.1.3.2.3 break //     4.1.3.3out_nInfoType = (*loc_Itr).m_nENUM; //     4.1.3.4 remove the entry fromthe vector //     4.1.3.5 if the vector is empty, return //    eWithValueNoMoreValue //     4.1.3.6 else returneWithValueMoreValues //    4.1.3 default //     4.1.3.1 ASSERT //    4.1.3.2 increment loc_Itr //     4.1.3.3 break //   5 returneNoValue//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: putParameters(std::vector<std::string> //  in_ParameterVector, const infoType in_InfoType) // Description: Thisfunction put the parameter vector to the //   structure and push thestructure into //   m_InfoStructureVector. // Preconditions: InputVector is not empty. in_InfoType is not //   eNotDefine //Postconditions: None // Algorithm: 1 if precondition are not met, return//   2 declare SInfoStructure loc_InfoStructure //   3 Assign thecorresponding parameter values in //    in_ParameterVector toloc_InfoStructure //    Note: convert from string to int for //   m_nInlinePosition //   4 push_back loc_InfoStructure to //   m_InfoStructureVector///////////////////////////////////////////////////////////////////////

APPENDIX 7 6.6.5.6.5.15 CSamsungStatusML2550ScriptProcess ClassSpecification   This process extracts the toner status from the Samsungprinters.   The data is located in the web page, /panel/setup.htm in thefollowing format. function RemainTonerOption( ) {  if((modelVer !=0x0701)&&(modelVer != 0x0702)&&(modelVer != 0x0703)&&(modelVer !=0x0711))  {   document.write(‘<tr><td width=“10” height=“35”></td><tdwidth=“263” height=“35”><font size=“2” face=“Arial”>Remain Toner:(100%)</font></td>’);   document.write(‘<td width=“381” height=“35”colspan=“2”><table border=“1” width=“300” cellspacing=“0”cellpadding=“0”><tr><td width=“300” height=“17”>’);  document.write(‘<table border=“0” height=“100%” width=“300”cellspacing=“0” cellpadding=“0”><tr>’);   document.write(‘<td width=“15”bgcolor=“#FFFFFF”></td><td width=“15” bgcolor=“#FFFFFF”></td>’);  document.write(‘<td width=“15” bgcolor=“#FFFFFF”></td><td width=“15”bgcolor=“#FFFFFF”></td>’);   document.write(‘<td width=“15”bgcolor=“#FFFFFF”></td><td width=“15” bgcolor=“#FFFFFF”></td>’);  document.write(‘<td width=“15” bgcolor=“#FFFFFF”></td><td width=“15”bgcolor=“#FFFFFF”></td>’);   document.write(‘<td width=“15”bgcolor=“#FFFFFF”></td><td width=“15” bgcolor=“#FFFFFF”></td>’);  document.write(‘<td width=“15” bgcolor=“#FFFFFF”></td><td width=“15”bgcolor=“#FFFFFF”></td>’);   document.write(‘<td width=“15”bgcolor=“#FFFFFF”></td><td width=“15” bgcolor=“#FFFFFF”></td>’);  document.write(‘<td width=“15” bgcolor=“#FFFFFF”></td><td width=“15”bgcolor=“#FFFFFF”></td>’);   document.write(‘<td width=“15”bgcolor=“#FFFFFF”></td><td width=“15” bgcolor=“#FFFFFF”></td>’);  document.write(‘<td width=“15” bgcolor=“#FFFFFF”></td><td width=“15”bgcolor=“#FFFFFF”></td>’);  document.write(‘</tr></table></td></tr></table><table border=“0”width=“300” cellspacing=“0” cellpadding=“0”>’);  document.write(‘<tr><td width=“100”><font face=“Arial”size=“2”>0%</font></td>’);   document.write(‘<td width=“100”align=“center”><font face=“Arial”   size=“2”>50%</font></td>’);document.write(‘<td width=“100” align=“right”><font face=“Arial” size=“2”>100%</font></td></tr></table></td></tr>’); } . . sDelimiter =“:(%”, nInlinePosition =1 , sPar1 = “RemainTonerOption”, sPar2 = “RemainToner”, nENUM = eBlack 6.6.5.6.5.15.1 Base Class  publicCAbsScriptProcess 6.6.5.6.5.15.2 Function List public: CSamsungStatusML2550ScriptProcess( );  virtual~CSamsungStatusML2550ScriptProcess( );  virtual void start(void); virtual CAbsScriptProcess::EReturn transformData(std::string&out_sValue infoType & out_nInfoType, const std::string in_sString); virtual void putParameters(std::vector<std::string> in_ParameterVector,const infoType in_InfoType); 6.6.5.6.5.15.3 Defined Type List  None.6.6.5.6.5.15.4 Class Attributes private: Type Attribute Name DescriptionSInfoStructure m_InfoStructure This attribute keeps the information usedto extract the status information. 6.6.5.6.5.15.5 Function Definitions///////////////////////////////////////////////////////////////////////// Function: CSamsungStatusML2550ScriptProcess( ) // Description:Constructor // Preconditions:  None. // Postconditions:  None. //Algorithm: 1 default//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: ~CSamsungStatusML2550ScriptProcess( ) // Description:Destructor // Preconditions:  None. // Postconditions:  None. //Algorithm: 1 default//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: start(void) // Description: This function sets the state toeStart // Preconditions:  None // Postconditions:  None // Algorithm: 1m_InfoStructure.m_State to eStart//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: transformData(std::string &out_sValue infoType & // out_nInfoType, const std::string in_sString) // Description: Thisfunction processes the input string to //  extract the value and itscorresponding //  infoType. If Abnormal condition happens //  thefunction returns eFinished. // Preconditions:  None. // Postconditions: None. // Algorithm: 1 set out_sValue to Null and out_nInfoType to //  eNotDefine //  2 declare size_t loc_Pos //  3 switch onm_InfoStructure.m_State //    3.1 case eStart: //     3.1.1 ifm_InfoStructure.m_sPar1 is found in //      in_sString,m_InfoStructure.m_State = //      ePrecon1 //     3.1.2 break //    3.2case ePrecon1: //     3.2.1 loc_Pos = //     in_sStning.find(m_InfoStructure.m_sPar2) //     3.2.2 if loc_Pos EQstd::string::npos, break //     3.2.3 declare loc_sLine = //     in_sStning.substr(loc_Pos) //     3.2.4 usingCExtractValueFromLine,if operator( ) //      passing out_sValueloc_sLine and other //      information passed in return false, //    3.2.4.1 ASSERT //     3.2.4.2 start( ) //     3.2.4.3 returneFinished //    3.2.5 out_nInfoType = m_InfoStructure.m_nENUM; //   3.2.6 start( ) //    3.2.7 return eWithValueNoMoreValue //   3.3default //    3.3.1 ASSERT //    3.3.2 start( ) //    3.3.3 returneFinished //   4 return eNoValue//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Function: putParameters(std::vector<std::string> //  in_ParameterVector, const infoType in_InfoType) // Description: Thisfunction put the parameter vector to the //   structure //Preconditions: Input Vector is not empty. in_InfoType is not //  eNotDefine // Postconditions:  None // Algorithm: 1 if preconditionare not met, return //   2 Assign the corresponding parameter values in//    in_ParameterVector to m_InfoStructure //    Note: convert fromstring to int for //    m_nInlinePosition///////////////////////////////////////////////////////////////////////

1. A method for extracting status information from within a script of aweb page stored on a monitored device using an abstract class interface,the abstract class interface including a first function configured toobtain support information used to extract the status information and asecond function configured to extract the status information from withinthe script of the web page using the support information, the methodcomprising: retrieving, from a first memory, vendor and modelinformation of the monitored device; determining, based on the vendorand model information, at least one type of status information to obtainfrom the monitored device; obtaining, based on the web page and thevendor and model information, the support information using the firstfunction of the abstract class interface; accessing the monitored deviceusing the HTTP protocol, the obtained support information, and thesecond function of the abstract class interface to obtain the at leastone type of status information from within the script of the web page;storing, in a second memory, the status information obtained in theaccessing step in association with the vendor and model information; anddetermining the at least one type of status information based on statusinformation that can be obtained from the monitored device and statusinformation that has already been obtained from the monitored deviceusing other communication protocols.
 2. The method of claim 1, whereinthe second function is configured to obtain the device informationwithin a JAVA script in an HTML file stored on the monitored device. 3.The method of claim 1, further comprising: repeating the obtaining,accessing, and storing steps for each web page associated with themonitored device.
 4. A computer-implemented system for extracting statusinformation from within a script of a web page stored on a monitoreddevice using an abstract class interface, the abstract class interfaceincluding a first function configured to obtain support information usedto extract the status information and a second function configured toextract the status information from within the script of the web pageusing the support information, the system comprising: a monitoringdevice including means for retrieving, from a first memory, vendor andmodel information of the monitored device; means for determining, basedon the vendor and model information, at least one type of statusinformation to obtain from the monitored device; means for obtaining,based on the web page and the vendor and model information, the supportinformation using the first function of the abstract class interface;means for accessing the monitored device using the HTTP protocol, theobtained support information, and the second function of the abstractclass interface to obtain the at least one type of status informationfrom within the script of the web page; means for storing, in a secondmemory, the status information obtained by the means for accessing inassociation with the vendor and model information; means for determiningthe at least one type of status information based on status informationthat can be obtained from the monitored device and status informationthat has already been obtained from the monitored device using othercommunication protocols.
 5. The system of claim 4, wherein the secondfunction is configured to obtain the device information within a JAVAscript in an HTML file stored on the monitored device.
 6. The system ofclaim 4, further comprising: means for causing the repeated execution ofthe means for obtaining, means for accessing, and means for storing foreach web page associated with the monitored device.
 7. Acomputer-readable storage medium having embedded therein instructions,which when executed by a processor, causes the processor to perform amethod for extracting status information from within a script of a webpage stored on a monitored device using an abstract class interface, theabstract class interface including a first function configured to obtainsupport information used to extract the status information and a secondfunction configured to extract the status information from within thescript of the web page using the support information, the methodcomprising: retrieving, from a first memory, vendor and modelinformation of the monitored device; determining, based on the vendorand model information, at least one type of status information to obtainfrom the monitored device; obtaining, based on the web page and thevendor and model information, the support information using the firstfunction of the abstract class interface; accessing the monitored deviceusing the HTTP protocol, the obtained support information, and thesecond function of the abstract class interface to obtain the at leastone type of status information from within the script of the web page;storing, in a second memory, the status information obtained by theaccessing sin association with the vendor and model information; anddetermining the at least one type of status information based on statusinformation that can be obtained from the monitored device and statusinformation that has already been obtained from the monitored deviceusing other communication protocols.
 8. The method of claim 7, whereinthe second function is configured to obtain the device informationwithin a JAVA script in an HTML file stored on the monitored device. 9.The method of claim 7, further comprising: causing the repeatedexecution of the instructions for obtaining, the instructions foraccessing, and the instructions for storing for each web page associatedwith the monitored device.
 10. A computer-implemented system forextracting status information from within a script of a web page storedon a monitored device using an abstract class interface, the abstractclass interface including a first function configured to obtain supportinformation used to extract the status information and a second functionconfigured to extract the status information from within the script ofthe web page using the support information, the system comprising: amonitoring device including a retrieving unit configured to retrieve,from a first memory, vendor and model information of the monitoreddevice; a first determining unit configured to determine, based on thevendor and model information, at least one type of status information toobtain from the monitored device; an obtaining unit configured toobtain, based on the web page and the vendor and model information, thesupport information using the first function of the abstract classinterface; an accessing unit configured to access the monitored deviceusing the HTTP protocol, the obtained support information, and thesecond function of the abstract class interface to obtain the at leastone type of status information from within the script of the web page; astoring unit configured to store, in a second memory, the statusinformation obtained by the accessing unit in association with thevendor and model information; a second determining unit configured todetermine the at least one type of status information based on statusinformation that can be obtained from the monitored device and statusinformation that has already been obtained from the monitored deviceusing other communication protocols.